Which integrations are available for this server?

Builds Amazon affiliate buy links by adding your Amazon Associates tag (and optional ascsubtag) to amazon.* product URLs found in your feeds, so search results and comparisons return properly tracked Amazon links.

How do I use dealfinder?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@dealfinder find noise-cancelling headphones under 150 EUR and compare the top two" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

dealfinder

by petrovicistefan

Overview Schema Source Related Servers Discussions Admin

TypeScript

Hybrid

mcp-dealfinder

An MCP server that lets an AI assistant search affiliate product feeds from any network and return buy links built with your own affiliate IDs. Works with Awin, Amazon, and any network that has deep links (CJ, Impact, 2Performant, Profitshare, …).

Every tracked link ships with a disclosure text, and the server tells the assistant to show it. Search results are ranked by relevance or price, never by commission.

Quick start

git clone https://github.com/petrovicistefan/mcp-dealfinder.git
cd mcp-dealfinder
npm install            # also builds
claude mcp add dealfinder -- node "$(pwd)/dist/index.js"

Claude Desktop (claude_desktop_config.json):

{
  "mcpServers": {
    "dealfinder": {
      "command": "node",
      "args": ["/absolute/path/to/mcp-dealfinder/dist/index.js"],
      "env": { "DEALFINDER_CONFIG": "/absolute/path/to/dealfinder.config.json" }
    }
  }
}

With no config it starts on fictional demo products, so you can try it immediately. Then ask: "find noise-cancelling headphones under 150 EUR and compare the top two".

Related MCP server: admitad-mcp

Tools

Tool	What it does
`search_products`	Keyword search with price / currency / network / merchant filters. Diacritics-insensitive. Up to 20 results.
`compare_products`	Side-by-side data for 2–5 products, marks the cheapest.
`get_buy_link`	The (affiliate) link for one product.
`dealfinder_status`	Feeds (counts, errors) and which networks produce tracked links.

All tools accept an optional sub_id to tag links (for example the post they appear in).

Configure your feeds

Copy examples/dealfinder.config.example.json to dealfinder.config.json (gitignored) and set DEALFINDER_CONFIG.

networks — your affiliate accounts, by name.
feeds — where products come from (CSV or JSON, local file or URL, .gz handled) and how columns map to fields. Prices like 1.299,99, 19,99 and € 24.50 are parsed.

Feed URLs often contain an API key. Keep them in dealfinder.config.json, never in a repository.

Network `kind`	Builds	Notes
`amazon`	adds `tag` (+ `ascsubtag`) to `amazon.*` URLs	Feed must contain product URLs. Amazon offers no product feeds, and its Creators API requires ≥10 qualifying sales in 30 days, so supply your own product URLs
`awin`	`awin1.com/cread.php` deep link	Needs `merchantId` (awinmid) on the feed
`template`	anything else	Copy the deep-link format from the network's own link builder and put `{urlEncoded}` where the destination goes. Also available: `{url}`, `{subId}`, any key from `params`

Not sure about a network's link format? Generate one link in the network's link generator for any product page, then run:

npm run link-template -- --link "<generated link>" --url "<product URL you pasted>" --name mynetwork

It prints the networks entry (IDs extracted, destination replaced by {urlEncoded}) and verifies it by rebuilding your link. The link contains only public IDs, never API keys.

Links that cannot be built (missing account, missing placeholder) fall back to the plain merchant URL and are reported as tracked: false — never a broken link.

Before connecting an assistant, validate everything:

DEALFINDER_CONFIG=$PWD/dealfinder.config.json npm run check

It loads every feed and reports product counts, field coverage, price range, sample links, and mistakes that would produce untracked links.

Compliance — please read

Use official feeds/APIs only; scraping breaks most networks' terms.
Check each program's terms before use, including whether promotion through AI assistants is allowed.
Use your own affiliate IDs on your own traffic. Do not rotate or share IDs between different people: networks attribute sales to the publisher who referred the visitor.
Do not buy through your own affiliate links; most programs forbid it.
Keep the disclosure visible next to affiliate links.
Prices are as of the last feed refresh (refreshHours, default 6) and are not converted between currencies.

Build on it

The package exports a library API. startServer / createServer accept registerExtras(server, toolkit) to add your own tools while reusing the product presentation and link building:

import { startServer, z } from "mcp-dealfinder";

await startServer({
  name: "my-dealfinder",
  registerExtras: (server, kit) => {
    server.registerTool("cheapest_of", { inputSchema: { refs: z.array(z.string()).min(2) } }, async ({ refs }) => {
      const { products } = kit.resolveRefs(refs);
      return kit.text(kit.present([...products].sort((a, b) => a.price - b.price)[0]!));
    });
  },
});

Development

npm test             # node:test: links, link-template, feeds, search, check, MCP server (in-memory)
npm run dev          # run from source over stdio
npm run build

src/
  config.ts       config schema + loader (falls back to demo data)
  feeds.ts        CSV/JSON/gzip loading, price parsing, FeedStore (refresh, per-feed errors)
  search.ts       ranked keyword search
  links.ts        affiliate deep links per network
  link-template.ts  derive a network template from one generated link
  check.ts        config/feed validation report
  server.ts       MCP tools + extension hook
  bootstrap.ts    config → feeds → server over stdio
  lib.ts          public library API

Author

Built by Stefan Petrovici, software engineer based in Iași, Romania, working with clients worldwide.

I'm open to work. I build web and mobile apps and take ideas from first sketch to production. I'm also interested in partnerships, and I work project-based or time-based. If you need an MCP server, an AI assistant for your shop or product, or a payments/integration problem solved, get in touch via petrovicistefan.ro.

License

MIT. Paid extensions built on this library are distributed separately.

Available Tools

4 tools

compare_productsCompare productsA

Read-only

Side-by-side data for 2–5 products (by ref). Marks the cheapest when all share one currency.

ParametersJSON Schema

Name	Required	Description	Default
`refs`	Yes
`sub_id`	No

TDQS

A3.6/5.0

Behavior4/5

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

Beyond readOnlyHint/openWorldHint, the description discloses a real output behavior: the cheapest product is marked, but only when all inputs share one currency. That conditional is genuinely useful context an agent could not get from the annotations. It still omits what happens on mixed currencies or output shape.

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?

Two short sentences, no filler, with the core scoping constraint and the cheapest-marking behavior front-loaded. Every clause earns its place.

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?

For a read-only, no-output-schema tool whose annotations already cover the safety profile, the description covers the essentials plus the currency condition. The gap is the unexplained `sub_id` parameter, which is the main reason this is not a 5.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description carries the full parameter burden. It explains that `refs` are product references limited to 2–5 (though the bounds already live in the schema) but says nothing about `sub_id` or its format, leaving one of two parameters entirely undocumented.

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?

States a specific verb+resource ('Side-by-side data for 2–5 products') and the identifier used ('by `ref`'), which is enough to distinguish it from search_products at a glance. It does not explicitly name the sibling it complements, so differentiation is implicit rather than stated.

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

Usage Guidelines3/5

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

The comparison intent is implied by the name and description, but there is no explicit when-to-use trigger, no prerequisite (e.g. obtaining refs from search_products first), and no mention of when not to use it. Adequate but inferential.

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

dealfinder_statusDealFinder statusA

Read-only

Shows loaded feeds (counts, last refresh, errors) and which networks produce tracked links.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.9/5.0

Behavior4/5

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. Beyond that, the description discloses the shape of what is returned (feed counts, last refresh, errors, which networks produce tracked links), which is valuable since there is no output schema.

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?

A single tight sentence that front-loads the resource (loaded feeds) and parenthetically enumerates the key data points. No wasted words.

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?

For a zero-parameter read-only status tool with no output schema, the description adequately covers what the agent will get back. It stops short of describing failure modes (e.g., what an error field implies) but is otherwise complete.

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?

The tool takes zero parameters, so there is nothing for the description to disambiguate. Baseline of 4 applies.

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 states a specific verb and resource: it reports loaded feeds with counts, last-refresh times, errors, and tracked-link networks. That is clearly distinguishable from product/link siblings like get_buy_link and search_products, though it doesn't explicitly name them.

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

Usage Guidelines3/5

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

No explicit when-to-use or when-not-to-use is given. Usage is only implied by the name and content (a diagnostic/health check for the DealFinder integration), so an agent must infer that this is for verifying feed and link-tracking state.

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

get_buy_linkGet buy linkC

Read-only

Return the (affiliate) link for one product by ref.

ParametersJSON Schema

Name	Required	Description	Default
`ref`	Yes
`sub_id`	No

TDQS

C2.7/5.0

Behavior2/5

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds only the parenthetical '(affiliate)', which hints at monetization context but says nothing about link lifetime, redirect behavior, required auth, or rate limits — little value beyond structured fields.

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?

A single short sentence with no filler, and the resource and key are front-loaded. It is efficient, though there is so little content that efficiency verges on under-specification.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an openWorld affiliate-link tool with an undocumented second parameter and no output schema, the description leaves an agent guessing about ref provenance, sub_id purpose, and the link's form. Annotations cover read safety only, so the description should do substantially more.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must carry parameter meaning, but it only names `ref` and never explains what a ref is or where to obtain it. The second parameter `sub_id` is not mentioned at all, leaving an affiliate sub-tracking argument completely undocumented.

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?

States a specific verb and resource ('Return ... link for one product') and names the lookup key (`ref`), so an agent can tell it apart from search_products and compare_products. It stops short of explicitly contrasting itself with those siblings, but the purpose is unambiguous.

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 on when to call this versus search_products, compare_products, or dealfinder_status, and no mention of prerequisites (e.g. needing a ref from a prior search). The implied workflow is left entirely to inference.

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

search_productsSearch productsA

Read-only

Search the loaded affiliate product feeds by keywords. Returns products with price, merchant and a buy link. Filters: price range, currency (no conversion), network, merchant. Use the returned ref in other tools.

ParametersJSON Schema

Name	Required	Description	Default
`sort`	No		relevance
`limit`	No
`query`	Yes	Keywords, e.g. 'noise cancelling headphones'. Diacritics are ignored.
`sub_id`	No	Optional tracking tag (e.g. a campaign or post name).
`network`	No	Restrict to one affiliate network key.
`currency`	No	ISO code, e.g. EUR. Only products in this currency match.
`merchant`	No	Restrict to merchants whose name contains this text.
`max_price`	No
`min_price`	No

TDQS

A3.6/5.0

Behavior4/5

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

Annotations already declare readOnlyHint and openWorldHint, so safety is covered. The description adds real behavioral context beyond that: results include price/merchant/buy link, filters are non-converting for currency, and the returned `ref` is meant to be passed into other tools. Pagination/result-count behavior (limit max 20) is left to the schema.

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?

Three tight sentences, front-loaded with purpose then return shape then filters then chaining. No filler; it could be marginally sharper by folding the filter list and ref note together, but nothing is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 9-parameter search tool with no output schema, the description covers purpose, return contents, and most filters, which is adequate. It stops short on sort/limit semantics and any note about result-set sizing or pagination, which an agent would otherwise have to dig out of the schema.

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?

Schema description coverage is 56%, and the description only names the filter families (price range, currency, network, merchant) without covering sort, limit, or the query semantics. The parenthetical '(no conversion)' for currency is a genuinely useful semantic addition the schema lacks, but the undocumented params (sort, limit) remain unaddressed.

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?

States a specific verb and resource ('Search the loaded affiliate product feeds by keywords') and summarizes what comes back (price, merchant, buy link). It does not explicitly distinguish itself from siblings like compare_products or get_buy_link, so an agent must infer the boundary.

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

Usage Guidelines3/5

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

Usage is implied by 'search ... by keywords', and 'Use the returned `ref` in other tools' gives useful downstream chaining guidance. However, there is no explicit when-to-use vs compare_products (which presumably also queries products) or a statement of when this is the wrong tool.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

4 tool updatesv0.1.0Oct 7, 2026
- First observedcompare_products
- First observeddealfinder_status
- First observedget_buy_link
- First observedsearch_products

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.5/5.0

Scored 2026-10-07 11:35 across 4 tools

Disambiguation4/5

Each tool has a distinct primary role: search finds products, compare juxtaposes 2-5 refs, get_buy_link resolves a single ref to a link, and status reports feed health. The only mild overlap is that search_products already returns a buy link, so get_buy_link's boundary is slightly less sharp, but the single-ref use case is clear.

Naming Consistency4/5

Three tools follow a clean verb_noun pattern (get_buy_link, search_products, compare_products). The status tool deviates slightly by prefixing the server name (dealfinder_status), but the set is still predictable and readable.

Tool Count5/5

Four tools is a tight, well-scoped surface for a read-only affiliate deal finder: search, inspect feeds, compare, and resolve links. Each tool earns its place with no redundancy.

Completeness4/5

The core lifecycle of finding, comparing, and linking products is covered, plus feed status. Minor gaps exist (no explicit single-product detail fetch beyond search, no category/browse or feed refresh), but agents can work around these using search results.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

Unified Offer Protocol MCP Server
com.unifiedoffer
AI-powered product search, affiliate links, and price negotiation for e-commerce platforms
E-commerce & Retail Search App Automation
2
agent-commerce
ai.petraport
AI-agent product catalog: search, lookup & purchase routing over verified merchant data.
E-commerce & Retail Search
2
price-tracker-mcp A
dev.ioconnex
Product price checks and affiliate link building for AI shopping agents.
E-commerce & Retail Marketing
21
Clickwise Affiliate Network AOAuth
net.clickwise
Affiliate programs, deals and tracked links, plus product search by text or GTIN.
E-commerce & Retail Marketing Search
201

Related MCP Servers

Godaloofficial
E-commerce & Retail Search
Godalo-ai
A
license
Not graded
quality
D
maintenance
Affiliate product search for AI agents. Indexes structured merchant feeds — real prices, live stock, affiliate links built in. Works with any MCP client.
Updated 4 months ago (2026-06-04 11:51 UTC)
MIT
admitad-mcp
E-commerce & Retail Marketing
gruzd1sok
F
license
A
quality
D
maintenance
Enables AI assistants to browse Admitad affiliate programs, discover product feeds, and search products directly from chat.
Updated 4 months ago (2026-06-02 15:28 UTC)
2
8
2
-
Synchronity
E-commerce & Retail Search
themewireco
A
license
Not graded
quality
C
maintenance
Enables AI assistants to search, compare, and buy products across connected WooCommerce stores with human-in-the-loop approval.
Updated 3 months ago (2026-07-25 19:25 UTC)
MIT
MCP Affiliate Server
E-commerce & Retail Marketing
Scientia07
A
license
A
quality
D
maintenance
Enables AI assistants to search products and generate affiliate links across European and global affiliate networks, automating product discovery and link creation for monetization.
Updated 8 months ago (2026-02-17 15:03 UTC)
5
MIT

mcp-dealfinder

Quick start

Tools

Configure your feeds

Compliance — please read

Build on it

Development

Author

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Godaloofficial