Read-only crypto signup codes, partner links, sourced campaign dates and the latest crypto news.
Scored across 5 tools
get_code, search_codes, and list_brands all surface codes/offers, and both search_codes and list_brands accept a category filter, creating genuine overlap. The descriptions do draw lines (exact lookup vs. fuzzy search vs. browse), which prevents outright confusion, but an agent may still pick the wrong entry point for a simple code lookup.
Four of five names follow a verb_noun pattern (get_code, list_brands, list_campaigns, search_codes) in consistent snake_case. latest_news breaks the pattern with an adjective_noun form and no verb, but it is still readable and idiomatic.
Five tools is on the lean side but each maps to a distinct content type (codes, brands, campaigns, news) and earns its place. Nothing looks padded or redundant enough to be a problem.
The surface covers discovery of codes, brands, campaigns, and news, but there are no detail-fetch tools (get_brand, get_campaign, get_story by id/slug) and latest_news appears limited to the newest items with no archive or news search. Agents can browse but may hit dead ends when they need a specific record.
Get a brand or alias, exact published code/link, offer type, instructions and caveats. A brand match never establishes region or product eligibility. Unknown brands return found:false.
| Name | Required | Description | Default |
|---|---|---|---|
| brand | Yes | Brand name, slug or alias, e.g. OKX or ether.fi. | |
| region | No | Optional region context. Does not establish eligibility. | |
| product | No | Optional product context. Does not establish eligibility. |
| Name | Required | Description |
|---|---|---|
| found | Yes | |
| offer | Yes | |
| notice | Yes | |
| disclosure | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint and idempotentHint already in annotations, the description adds valuable behavioral context: 'A brand match never establishes region or product eligibility' and 'Unknown brands return found:false.' These state important data semantics that the annotations alone do not convey.
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 two compact sentences with no filler, front-loading the core retrieval purpose and then adding the two most important caveats. Every sentence contributes essential 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?
The tool is simple, the schema is fully described, and an output schema exists, so the description does not need to enumerate return fields. It covers the key caveats and unknown-brand behavior, making it complete enough for an agent to call the tool correctly.
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 the baseline is 3. The description mostly restates what the schema already says, such as brand or alias and the eligibility caveat for region/product. It adds no meaningful parameter-level detail beyond the schema's existing descriptions.
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 ('Get') and a precise resource ('a brand or alias'), and lists the exact returned content: published code/link, offer type, instructions and caveats. The phrase 'one brand offer' in the title and the focus on a single brand clearly distinguishes it from sibling list/search tools.
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 description implies the tool is for retrieving a single brand's offer by brand name or alias, but it does not explicitly say when to prefer this over list_brands or search_codes. No exclusions or alternative routing are provided, so usage guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the latest Exchange.news stories, newest published first (published_at is the site publication time; date is the announcement date), with title, brand, date, summary and canonical URL. Optional exact brand, slug or alias filter. Stories report official announcements; they are not offers or eligibility checks.
| Name | Required | Description | Default |
|---|---|---|---|
| brand | No | Optional exact brand, slug or alias, e.g. Base or Phantom. | |
| limit | No | ||
| offset | No |
| Name | Required | Description |
|---|---|---|
| count | Yes | |
| total | Yes | |
| notice | Yes | |
| offset | Yes | |
| articles | Yes | |
| has_more | Yes | |
| disclosure | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds real value beyond that: ordering guarantee, the distinction between published_at (site publication time) and date (announcement date), and the content caveat that these are announcements rather than offers. It omits pagination behavior across the limit/offset range and any rate-limit notes.
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?
Front-loads the core action and ordering, then adds the filter and the semantic caveat in two short sentences; nothing is padding. The first sentence is dense with a parenthetical field-semantics clause, which is justified but slightly cramped.
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?
An output schema exists, so the description need not spell out return values, and the annotation set covers the safety profile. What remains thin is pagination guidance for limit/offset and any indication of result-set size or total counts, but overall an agent has enough to call this correctly.
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 33%: only 'brand' is documented, and the description's 'optional exact brand, slug or alias filter' largely mirrors that. The limit and offset parameters have no description in either the schema or the description, so default/max behavior and pagination semantics must be inferred from the schema constraints alone.
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 ('List the latest Exchange.news stories') plus ordering ('newest published first') and the fields returned. None of the siblings (get_code, list_brands, list_campaigns, search_codes) touch news, and the description makes the resource 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?
Gives a clear boundary: 'Stories report official announcements; they are not offers or eligibility checks,' which steers the agent away from using this for offer/eligibility queries. It also frames the brand filter as optional exact matching. It does not name a sibling alternative for related lookups (e.g., list_brands), so it stops short of full when/when-not/alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Browse brands with their public offer type, visible code or null, lifetime signup link and full conditions. Optional exact category filter. No live eligibility check.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| offset | No | ||
| category | No | Optional category: exchanges, wallets, cards, hardware, analytics or defi. |
| Name | Required | Description |
|---|---|---|
| count | Yes | |
| total | Yes | |
| brands | Yes | |
| notice | Yes | |
| offset | Yes | |
| has_more | Yes | |
| disclosure | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds the 'No live eligibility check' note, which is not covered by annotations, and clarifies that the visible code can be null. This provides extra behavioral context beyond the structured metadata.
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 extremely concise, consisting of three short sentences that front-load the main purpose and include the key filtering option. Every sentence contributes value with no fluff.
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?
Given an output schema exists and read-only annotations are present, the description covers the essential return contents (offer type, code, link, conditions) and notes the absence of live eligibility checks. Pagination behavior is left to the schema, which is acceptable.
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 only 33% (category has a description). The description mentions the optional category filter but does not elaborate on limit or offset parameters, which remain undocumented in both schema and description. It adds minimal meaning beyond the schema for category and nothing for pagination.
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 clearly states the tool lists brands with specific attributes (public offer type, visible code or null, lifetime signup link, full conditions) and an optional exact category filter. This distinguishes it from siblings like list_campaigns (campaigns) and search_codes (codes), making the purpose 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?
The description implies usage for browsing brands but does not explicitly mention when to use this tool versus alternatives like search_codes or list_campaigns. There is no exclusion or routing guidance, so an agent must infer from the purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List source-backed campaign announcements, official source links and published event windows. Dates are independent of lifetime referral codes. Does not claim campaigns are active or that a user qualifies.
| Name | Required | Description | Default |
|---|---|---|---|
| brand | No | Optional exact provider brand, slug or alias. | |
| limit | No | ||
| offset | No |
| Name | Required | Description |
|---|---|---|
| count | Yes | |
| total | Yes | |
| notice | Yes | |
| offset | Yes | |
| has_more | Yes | |
| campaigns | Yes | |
| disclosure | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already establish readOnly, idempotent, non-destructive, and closed-world behavior. The description adds valuable nuance beyond those annotations: dates are independent of lifetime referral codes, and the tool does not claim campaigns are active or that a user qualifies. This clarifies semantic boundaries the annotations cannot express.
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?
Three short sentences, each carrying distinct meaning: what is listed, how dates behave, and what the listing does not assert. It is front-loaded and contains no filler, repetition, or unnecessary detail.
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?
Given the presence of an output schema, annotations covering safety/idempotency, and only three optional parameters, the description covers the semantic essentials. It could add more context about pagination or brand filtering, but those are at least partially encoded in the input schema. The main gap is already scored under parameter semantics.
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 only 33% – only 'brand' has descriptive text, while 'limit' and 'offset' rely on numeric constraints. The description adds no parameter-level meaning, leaving the undocumented parameters underspecified for a tool with low schema coverage. It should have compensated but does not.
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 verb and resource: 'List source-backed campaign announcements, official source links and published event windows.' It is distinctly about campaigns and explicitly clarifies a non-claim about activity or user qualification, which helps differentiate it from code/brand tools. It does not explicitly name sibling alternatives, but the purpose itself 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?
The description implies usage context by stating that dates are independent of referral codes and that it does not assert campaign activity or user eligibility. However, it never explicitly states when to prefer this tool over sibling tools like search_codes or get_code, nor does it state exclusions or when-not-to-use conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search brand aliases, categories and benefits. Generic promo/code words are ignored. Exact brand matches come first. Returns only catalog records; unknown queries return an empty array. Product and regional applicability remain subject to each caveat.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | Search text, e.g. OKX EU stock perps discount. | |
| offset | No | ||
| region | No | Optional region context. Does not establish eligibility. | |
| product | No | Optional product context. Does not establish eligibility. |
| Name | Required | Description |
|---|---|---|
| count | Yes | |
| total | Yes | |
| notice | Yes | |
| offset | Yes | |
| results | Yes | |
| has_more | Yes | |
| disclosure | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive behavior. The description adds meaningful behavioral details: generic promo/code words are ignored, exact brand matches are prioritized, only catalog records are returned, unknown queries yield an empty array, and product/region do not establish eligibility. These are valuable clarifications beyond the annotations.
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 compact and front-loaded, with each sentence contributing meaningful information. It covers matching behavior, ordering, return type, empty results, and caveats without unnecessary filler. This is an efficient, well-structured description.
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 search tool with an output schema and clear safety annotations, the description covers the most important behavioral aspects: what is searched, matching rules, ordering, empty results, and non-eligibility caveats. Minor gaps remain around pagination and how limit/offset interact with the result list, but these are partly addressed by the schema and output schema.
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 60%, with query, region, and product described in the schema. The description adds context by noting matching behavior and that product/regional applicability is caveated, which enriches region and product semantics. However, it does not clarify limit or offset semantics, and it does not fully compensate for the missing schema descriptions.
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 clearly identifies the action ('Search') and the resources: brand aliases, categories, and benefits. It adds behavioral specifics such as exact brand matches first and catalog-record-only returns, making the tool's purpose easy to grasp. It does not explicitly distinguish itself from siblings like list_brands or get_code, so it stops short of a 5.
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 description implies when to use the tool: it is for searching brand aliases, categories, and benefits, and generic promo/code words are ignored. However, it gives no explicit when-not-to-use guidance or references to sibling tools such as get_code or list_brands. Usage context is mostly implied rather than stated.
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.
latest_news2 fields changedOutput schema / properties / articles / items / properties / published_atAdded value: +{
+ "type": "string"
+}Output schema / properties / articles / items / requiredPrevious value: -[
- "id",
- "title",
- "brand",
- "provider",
- "category",
- "canonical_url",
- "date",
- "summary"
-]New value: +[
+ "id",
+ "title",
+ "brand",
+ "provider",
+ "category",
+ "canonical_url",
+ "date",
+ "published_at",
+ "summary"
+]latest_newsget_codelist_brandslist_campaignssearch_codesVerified referral and discount codes for crypto exchanges, wallets and trading tools. Read-only.
Verified discount & referral codes for crypto exchanges, cards and more — tested first-hand.
Sourced, scored comparisons of crypto exchanges, wallets, savings accounts and brokerages.
Source-verified crypto news, live prices, whale transfers, token safety checks and the Daily Brief.
Add one secure layer between your agents and this server.
