Search no-KYC exchanges, swaps, wallets and VPNs with privacy and safety grades.
Scored across 6 tools
Each tool has a clearly distinct purpose: search, get one listing, compare two listings, rank within a category, list categories, and list incidents. The only mild overlap is that search/rank both return service lists and get_service includes incidents, but the descriptions make the intended selection unambiguous.
All tool names use a consistent snake_case verb_noun pattern: compare_services, get_service, list_categories, list_incidents, rank_category, search_services. There are no mixed conventions or vague standalone verbs.
Six tools is well-scoped for a read-only service-rating directory. The set covers discovery, lookup, comparison, category ranking, and incident browsing without redundant tools.
The surface covers the core NoKYC Score workflows: searching, viewing a service, comparing services, ranking categories, and reviewing incidents and categories. A minor gap is the lack of an explicit list-all-services browse operation, but search and category ranking largely work around it.
Side-by-side grades, KYC levels and incident counts for two listed services.
| Name | Required | Description | Default |
|---|---|---|---|
| a | Yes | First service (slug, name or domain). | |
| b | Yes | Second service. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds useful context about the compared metrics but does not discuss return format, error behavior, or limits; with annotations doing the heavy lifting, a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with zero waste. Every element (side-by-side, metrics, two listed services) contributes directly to understanding the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only comparison tool with no output schema, the description is nearly complete: it names the compared metrics and specifies two services. Minor gaps remain around what 'listed' means and how invalid inputs are handled, but nothing essential to calling the tool is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters (a and b) are fully documented in the schema, including acceptable formats for a. The description adds no parameter-level detail beyond what the schema provides, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb (compare) and resource (services), and enumerates what is compared (grades, KYC levels, incident counts). It implicitly distinguishes from get_service by requiring two services, but does not explicitly name the sibling or contrast the use case.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The use case is implied by 'side-by-side ... for two listed services', but the description gives no explicit when-to-use guidance, prerequisites, or alternatives such as get_service or search_services. An agent must infer the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full listing for one service: KYC level and what the terms say about ID, Privacy and Safety grades with the points behind them, features and warnings, fees and limits, and every recorded incident with its source. Answers "is X safe / legit / a scam / no-KYC?".
| Name | Required | Description | Default |
|---|---|---|---|
| service | Yes | Slug, name or website domain, e.g. "fixedfloat", "FixedFloat" or "ff.io". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered; the description goes further by disclosing exactly what the response contains, including that incidents carry their source. It does not say what happens for an unrecognized slug or whether results are cached/fresh, which are the remaining behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core statement ('Full listing for one service') before the field enumeration, and the intent question lands last as a hook. The middle clause is a dense comma-run, but each item names real returned data rather than filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 correctly shouldered the burden of describing return contents, and it does so thoroughly across KYC, grades, features, fees, limits, and incidents. Only not-found/error behavior is missing for a single-key lookup tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single 'service' parameter is documented with accepted forms (slug, name, domain) plus three examples. The description adds nothing about the parameter, so the schema does all the work — baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific resource and scope: a full record for exactly one service, enumerating the sections returned (KYC level, grades, fees, incidents). This implicitly separates it from search_services and compare_services, but never names those siblings, so the differentiation is inferential rather than explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The closing sentence — 'Answers "is X safe / legit / a scam / no-KYC?"' — gives a concrete decision context that tells an agent when this tool is the right pick. No exclusions or prerequisites are stated, and no alternative tools are named for the case where the service is unknown or a bulk lookup is wanted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Every category with its key, page, number of live listings and the feature keys rank_category accepts for it.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds genuinely new context by describing the return payload (keys, pages, live listing counts, feature keys) despite no output schema existing — though it omits whether the list is paginated or exhaustive in size.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler. It is slightly dense because return fields are packed into one clause, but every element carries information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description must convey what comes back, and it does list the four returned items. Gaps remain around cardinality/pagination and how 'live listings' is defined, which an agent might want for large catalogs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the baseline is 4. The description correctly implies a parameterless full enumeration, consistent with the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the resource (every category) and enumerates returned fields (key, page, live listings, rank_category feature keys), which clearly distinguishes it from siblings like rank_category and get_service. It lacks an explicit verb like 'list' but the intent is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Mentioning that it supplies 'the feature keys rank_category accepts' implies a call-this-before-rank_category workflow, but the relationship is only hinted at rather than stated. No explicit when-to-use or when-not-to-use guidance is given against alternatives like search_services.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recorded incidents (held funds, hacks, exit scams, shutdowns, policy changes), newest first, each with its public source. Optionally for one service.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| service | No | Optional service slug, name or domain. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered and the bar is lower. The description still adds useful traits beyond them: results are ordered newest-first and each record carries a public source field. It stops short of disclosing result-set size behavior or whether results are truncated at the limit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences, front-loaded with the resource and its scope. Every clause carries information (categories, ordering, included field, optional filter) with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-required-parameter, read-only list tool with annotations present, the description covers what is returned, how it is ordered, and how to narrow it. With no output schema, a brief note on what happens at the limit boundary would make it fully complete, but nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%: 'service' is self-documented in the schema, and the description reinforces it by clarifying that it filters to a single service ('for one service'). 'limit' is never mentioned in the description, though its default/max/min make it self-explanatory in the schema. Adequate, with the schema doing most of the work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource (list recorded incidents) and immediately enumerates the incident categories covered (held funds, hacks, exit scams, shutdowns, policy changes). The resource is plainly distinct from the service/category-oriented siblings, so an agent can route on it without opening a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Optionally for one service' signals that filtering is optional and scoped to a single service, which is real usage context. However, it never says when to use this versus a sibling, nor does it name any alternative or exclusion — usage is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The best-graded services in one category, sorted by Safety (default) or Privacy, with services that never or rarely ask for ID first and those whose terms let them demand ID (KYC level 3) after them. Services that require ID from every user are left out, as on the site. Optionally keep only services with given features.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | safety | |
| limit | No | ||
| category | Yes | Category key; see list_categories. | |
| must_have | No | Feature keys to require, e.g. ["monero", "no-account", "onion"]. list_categories shows the keys for each category. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so safety profile is covered. The description nonetheless adds real behavioral detail: the ranking order, the default sort, and the exclusion of services requiring ID from every user, mirroring site behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single dense sentence that front-loads what is returned and the default ordering before the exclusion rules and optional filter. It is efficient but the nested clauses make it slightly hard to parse in one pass.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, and the description never indicates what a returned entry looks like (names, grades, feature flags, ordering metadata) or how many results the default limit yields. Enough to call it correctly, not enough to predict the response shape.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 50% schema coverage, the description usefully clarifies that 'sort' selects Safety by default or Privacy, and that 'must_have' keeps only services with the given features. 'limit' is left to the schema (min/max/default), which is adequate but not reinforced.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific action (ranking services within one category), the ordering dimension (Safety default, or Privacy), and precise inclusion/exclusion rules (KYC-level-3-required services listed last, per-user ID requirement excluded). An agent can distinguish this from list_categories or search_services without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear context for when this is the right call — you want a ranked shortlist within a category and may filter by required features — and explains the default sort. It does not explicitly name alternatives (e.g. compare_services or search_services) or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find no-KYC services by name, website domain or description, optionally within one category. Returns each match with its KYC level, Privacy and Safety grades and incident count.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | Name, domain or keywords, e.g. "trocador", "monero swap", "vpn". | |
| category | No | Optional category key. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the safety profile (readOnlyHint=true, openWorldHint=false), and the description adds genuinely non-obvious behavior: the index is restricted to no-KYC services, and each hit carries KYC level, Privacy/Safety grades, and incident count. It omits ranking/ordering behavior for matches, which keeps it short of a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero filler, with the search scope front-loaded and return shape second. Nothing repeats the title verbatim.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description usefully summarizes returned fields, and the three-parameter surface is simple. Missing only ordering/relevance behavior and how the limit interacts with total results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67%: query and category are already documented in the schema, and the description largely restates them. The description does clarify that category scoping is optional ('optionally within one category'), but says nothing about the undocumented limit parameter beyond what its default/max implies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Find no-KYC services') plus the matching fields (name, website domain, description) and an optional category scope. It is clearly a search-style lookup, distinct from siblings like get_service or rank_category, though it never names an alternative explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the matching-field enumeration: use it when you have a name, domain, or keyword. There is no explicit when-not guidance and no routing to siblings such as get_service (single lookup) or compare_services, leaving the agent to infer the boundary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
compare_servicesget_servicelist_categorieslist_incidentsrank_categorysearch_servicesKeyless web, GitHub, YouTube and Reddit search and read. Delegated shop, booking and signup.
No-KYC crypto swaps, no account or email. Read-only quotes, coins, swap links, order status.
Countries have borders. You don't. Privacy-first, read-only eSIM catalogue for travel connectivity (countries, packages, SIM registration rules). VPN and Card coming soon. Website: https://librepass.co
Free wallet lookup, ENS, labels, caller ID. Paid x402: search, scrape, XRP yield and lending grades
Add one secure layer between your agents and this server.
