This server exposes the FlexOffers affiliate marketing API (v3) as MCP tools, enabling you to manage affiliate programs, products, promotions, and earnings from AI clients like Claude Desktop, Cursor, or Windsurf.
Browse Advertiser Programs – List, search, and filter affiliate programs by name, category, country, or approval status (fo_list_advertisers, fo_get_featured_advertisers)
Explore Categories – Retrieve all advertiser categories for filtering (fo_get_categories)
Find Promotions & Coupons – Fetch active coupons and promotions filtered by advertiser, category, date range, discount amount, or promo type (fo_list_promotions, fo_get_promotion_types)
Search Products – Search by name, brand, UPC/EAN, or catalog ID with lightweight or full detail responses (fo_search_products, fo_search_products_full, fo_list_catalogs, fo_count_products)
Generate Affiliate Deep Links – Monetize any merchant URL with a tracked affiliate link (fo_generate_deeplink)
Browse Credit Card Offers – List financial card offers filtered by network, credit rating, or advertiser (fo_list_cards)
Track Earnings & Payments – View payout summaries and per-advertiser breakdowns for any date range (fo_get_payment_summary, fo_get_payment_details)
Analyze & Export Reports – List sales with status/date filters, or export performance reports (clicks, approved/pending sales) as CSV, Excel, or XML (fo_list_all_sales, fo_export_report)
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@flexoffers-mcp list my approved advertisers in electronics"
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.
MCP server para la API de FlexOffers v3. Expone los endpoints más útiles como tools para Claude Desktop, Cursor, Windsurf, o cualquier cliente compatible con MCP.
cd flexoffers-mcp
npm install
npm run buildRelated MCP server: CJ MCP Server
Edita ~/Library/Application Support/Claude/claude_desktop_config.json:
{
"mcpServers": {
"flexoffers": {
"command": "node",
"args": ["/ruta/absoluta/a/flexoffers-mcp/dist/index.js"],
"env": {
"FLEXOFFERS_API_KEY": "tu_api_key_aqui"
}
}
}
}Agrega al archivo de configuración MCP del IDE:
{
"mcpServers": {
"flexoffers": {
"command": "node",
"args": ["/ruta/absoluta/a/flexoffers-mcp/dist/index.js"],
"env": {
"FLEXOFFERS_API_KEY": "tu_api_key_aqui"
}
}
}
}FLEXOFFERS_API_KEY=xxx npm run devTool | Descripción |
| Lista/busca programas de afiliados con filtros |
| Obtiene todas las categorías |
| Anunciantes destacados |
| Cupones y promociones activas |
| Tipos de promoción disponibles |
| Busca productos en el catálogo |
| Productos con datos completos (precio, descuentos) |
| Lista catálogos de productos disponibles |
| Cuenta productos antes de un pull masivo |
| Genera un link de afiliado monetizado |
| Ofertas de tarjetas de crédito |
| Resumen de pagos por periodo |
| Detalle de pagos por anunciante |
| Lista ventas de |
| Exporta reporte de clicks o ventas (CSV) |
¿Cuáles son mis advertisers aprobados en la categoría de electrónicos?
→ usa fo_list_advertisers con ProgramStatus=Approved
Dame los mejores cupones activos de hoy
→ usa fo_list_promotions con couponsOnly=true y startDate de hoy
Genera un deeplink para https://amazon.com/producto/123
→ usa fo_generate_deeplink
¿Cuánto gané en marzo 2026?
→ usa fo_get_payment_summary con startdate=03/01/2026 enddate=03/31/2026
Trae las ventas de ayer con detalle de productos
→ usa fo_list_all_sales con status=all, reportType=details, startDate=07/16/2026, endDate=07/16/2026, dateType=eventDate, page=1, pageSize=500Count products for a given catalog or filter before doing a full pull.
| Name | Required | Description | Default |
|---|---|---|---|
| cid | No | Catalog ID | |
| name | No | ||
| manufacturer | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses a read-only count operation but does not detail other behaviors like rate limits or response format. Adequate but not rich.
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, well-structured sentence of 11 words with no wasted text.
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 3 parameters, no output schema, and no annotations, the description is minimal. It lacks details about output format, parameter requirements, and combination rules, making it insufficient for safe autonomous use.
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 low (33%); only 'cid' has a description. The tool description hints that 'name' and 'manufacturer' are filter criteria but does not explicitly explain their role or constraints.
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 verb 'count', the resource 'products', and the context 'for a given catalog or filter'. It distinguishes from sibling tools like fo_search_products by implying a lightweight count before a full pull.
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 phrase 'before doing a full pull' provides clear usage context, suggesting it is a preliminary step. However, it does not explicitly state when not to use or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Export a performance report (clicks, approved sales, pending sales) for a date range. Returns CSV data as text.
| Name | Required | Description | Default |
|---|---|---|---|
| EndDate | Yes | End date MM/DD/YYYY | |
| StartDate | Yes | Start date MM/DD/YYYY | |
| ReportType | Yes | C = Clicks, ASE = Approved Sales/Events, ASP = Pending Sales/Events | |
| ReportFormat | No | CSV (default), EXCEL, XML |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description implies read-only operation ('Export') and return format (CSV text). No annotations exist, so description provides basic transparency but omits details like permissions, rate limits, or side effects.
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, no redundant words, front-loaded with purpose. Every word adds value.
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 no output schema, description states return format (CSV text). However, it doesn't clarify that output format can be changed via ReportFormat parameter, potentially misleading if user selects EXCEL or XML. Otherwise adequate for a simple export 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 description adds no new meaning beyond mapping 'clicks, approved sales, pending sales' to ReportType and 'date range' to date parameters. Baseline score of 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?
Description clearly states verb 'Export' and resource 'performance report', specifies data types (clicks, approved sales, pending sales), and indicates output format. Distinguishes from siblings like fo_count_products or fo_get_payment_details.
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?
No explicit guidance on when to use or when not to use, nor comparison to siblings. Implies usage for generating performance reports but lacks context like prerequisites or typical scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a monetized FlexOffers deep link for any merchant URL. Returns the affiliate tracking URL.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The merchant product/page URL to monetize | |
| linkType | No | Link type: Text, Banner | |
| advertiserId | No | Optional advertiser ID (improves link accuracy) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description takes on full behavioral disclosure. It states the tool returns a URL, implying a read-like operation with no persistent side effects, but does not explicitly confirm this or mention any required authentication, rate limits, or potential for modification of system state. The behavior is straightforward but underexplained.
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, 14 words, front-loaded with the action and result. Every word earns its place. Highly efficient.
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 schema covers all parameters and the tool is simple, the description is mostly complete. It states the return value (affiliate tracking URL) which compensates for the lack of output schema. However, it could briefly explain the purpose of 'linkType' and 'advertiserId' to aid understanding.
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?
Input schema covers 100% of parameters with descriptions, so baseline is 3. The description adds no extra meaning beyond the schema; it only relates to the 'url' parameter by mentioning 'any merchant URL'. Details for 'linkType' and 'advertiserId' are absent from the description.
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 generates a monetized deep link for any merchant URL and returns the affiliate tracking URL. The verb 'generate' and resource 'deep link' are specific, and the tool is distinct from siblings focused on search, reports, and lists.
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 (to monetize a merchant URL with an affiliate link) but provides no explicit guidance on when not to use it or how it compares to sibling tools like 'fo_search_products' or 'fo_list_promotions'. No prerequisites or exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all FlexOffers advertiser categories (for building filter UIs).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the tool is a simple read-only retrieval with no parameters; the description adequately conveys behavior without needing additional details.
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?
Single sentence, front-loaded with purpose and use case, no wasted words.
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-parameter, no-output-schema tool, the description is complete enough, covering purpose and intended use.
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?
No parameters exist, so schema coverage is 100% and baseline is 4; the description adds no parameter info as there are none.
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?
Description clearly states it gets all FlexOffers advertiser categories and specifies the use case for building filter UIs, differentiating it from sibling 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 usage for building filter UIs, providing clear context, but does not explicitly exclude other uses or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get featured/promoted advertiser programs.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| Country | No | 2-letter country code | |
| pageSize | No | ||
| categoryIds | No | Comma-separated category IDs |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It simply repeats the tool's purpose without mentioning return format, pagination, authentication, or any side effects.
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 (5 words) but under-specified to the point of being unhelpful. It does not earn its place as it provides minimal actionable 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?
Given the lack of output schema, 4 parameters, and no annotations, the description fails to explain return values, pagination behavior, or the meaning of 'featured/promoted,' leaving the agent with insufficient context.
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% (Country and categoryIds have descriptions). The description adds no meaning for 'page' or 'pageSize' and does not clarify how parameters affect results.
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 'Get featured/promoted advertiser programs,' which clearly indicates a retrieval action on a specific resource. However, it does not explicitly differentiate from sibling tools like 'fo_get_categories' or 'fo_get_payment_details,' which also retrieve specific entities.
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 provides no guidance on when to use this tool versus alternatives, nor does it mention any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed payout breakdown by advertiser for a date range.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| enddate | Yes | End date MM/DD/YYYY | |
| pageSize | No | ||
| startdate | Yes | Start date MM/DD/YYYY |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description alone must disclose behavior. It correctly identifies the operation as a read ('Get'), but does not mention pagination, rate limits, or performance implications. The description is minimally transparent.
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, concise sentence that front-loads the tool's purpose with no unnecessary words. Every word earns its place.
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 description is minimal for a tool with 4 parameters and no output schema. It hints at the return structure ('detailed payout breakdown by advertiser') but omits pagination behavior, filtering options, and output format. Adequate but not complete.
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 50% (only date params described). The description adds no parameter-specific meaning beyond 'by advertiser', which is vague. It does not explain 'page' or 'pageSize' parameters. Baseline is 3, but missing detail for half the parameters.
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 a specific verb ('Get'), resource ('detailed payout breakdown by advertiser'), and scope ('for a date range'). It distinguishes from the sibling tool 'fo_get_payment_summary' which likely provides a summary, making the unique purpose clear.
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: use when needing detailed payout breakdown by advertiser versus summary. However, there is no explicit guidance on when to use this tool instead of alternatives, nor any conditions or exclusions. The description lacks context for selecting this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get payout summary for a date range. Returns total commissions earned.
| Name | Required | Description | Default |
|---|---|---|---|
| enddate | Yes | End date MM/DD/YYYY | |
| startdate | Yes | Start date MM/DD/YYYY |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It states 'Get' and 'Returns total commissions earned,' implying a safe read operation, but it does not confirm that no data is modified, or mention any authorization, rate limits, or potential side effects.
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 concise sentences with no extraneous information. The purpose and output are immediately clear.
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 tool with 2 simple parameters and no output schema, the description is adequate but minimal. It covers the basic function but lacks details on expected values, timezone usage, or example outputs, which could be helpful for an AI agent.
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%, with descriptions already defining the format 'MM/DD/YYYY' for both parameters. The description adds only that it uses a 'date range,' which does not provide additional semantic value beyond what the schema offers.
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?
Description clearly states the action ('Get'), resource ('payout summary'), scope ('for a date range'), and output ('Returns total commissions earned'). It is specific and distinguishes from sibling tools like fo_get_payment_details which implies more detailed data.
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?
No explicit guidance on when to use this tool versus alternatives (e.g., fo_get_payment_details). While the name and description imply it is for summary vs details, there is no direct comparison or recommendation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all promotion type categories (banner, coupon, sale, etc.) with their IDs.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It implies a read operation but lacks details on authentication, rate limits, or whether the data is cached. Minimal disclosure beyond basic purpose.
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?
One sentence, front-loaded with the core purpose. Every word adds value; no redundancy.
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 could better explain the return format (e.g., list of objects with id and name). Currently only mentions IDs, leaving ambiguity about other fields. Adequate but not complete.
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 input schema has no parameters, so the description does not need to add parameter detail. It adds context by mentioning categories and IDs, which is beneficial. Baseline 4 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 clearly states the tool retrieves all promotion type categories (with examples like banner, coupon, sale) and their IDs. It is specific and distinguishes from sibling tools that operate on different entities.
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?
No guidance on when to use this tool versus alternatives like fo_list_promotions or fo_get_categories. The description is self-contained but provides no context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List or search advertiser programs. Filter by approval status, category, country, or name. Returns program details including commission rates and tracking links.
| Name | Required | Description | Default |
|---|---|---|---|
| Name | No | Search advertisers by name | |
| page | No | Page number (default 1) | |
| Country | No | 2-letter country code (e.g. US, MX) | |
| pageSize | No | Results per page (default 50, max 200) | |
| categoryIds | No | Comma-separated category IDs to filter | |
| ProgramStatus | No | Filter by program status: Approved, Pending, Declined, Paused | |
| ApplicationStatus | No | Publisher application status: Applied, NotApplied, Approved, Declined | |
| ProductAdvertiser | No | Only return advertisers with product feeds |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the tool returns program details, but lacks information on safety, authentication, rate limits, or pagination behavior. Adequate but not rich.
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 with no wasted words. Purpose is front-loaded, followed by filters and return info. Highly efficient.
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?
No output schema, but the description covers filtering and return details. Lacks explicit mention of pagination (page/pageSize) and ordering. For a list tool, this is a minor gap, but overall complete.
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% (baseline 3). The description summarizes filter types (approval status, category, country, name) but does not add significant detail beyond the schema parameter descriptions. Adds marginal value.
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 or searches advertiser programs and specifies filtering options (approval status, category, country, name) and return details (commission rates, tracking links). It differentiates from siblings like fo_get_featured_advertisers.
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 general listing/searching but does not explicitly guide when to use this tool over alternatives (e.g., fo_get_featured_advertisers). No when-not or exclusion criteria provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List financial card offers (credit cards, rewards cards) from FlexOffers.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| pageSize | No | Max 1000 | |
| isFeatured | No | ||
| categoryIds | No | ||
| advertiserIds | No | ||
| creditCardName | No | ||
| creditCardNetwork | No | Visa, Mastercard, Amex, Discover | |
| consumerCreditRating | No | Excellent, Good, Fair, Limited, Bad |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description only says 'list', but does not disclose whether it is read-only, any rate limits, pagination behavior, or side effects. Heavy burden on description, not met.
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?
Single sentence, front-loaded with verb, no unnecessary words. Perfectly concise.
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 8 parameters, no annotations, no output schema, and 13 sibling tools, the one-sentence description is inadequate. No information on return values, filtering, or usage context.
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?
Description adds no meaning to the 8 parameters. Schema description coverage is only 38%, and the description does not compensate by explaining any parameter semantics beyond what is in the 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?
Clearly states the verb 'list', resource 'financial card offers', and source 'FlexOffers', with specific examples (credit cards, rewards cards). Distinct from sibling tools like fo_list_advertisers or fo_list_promotions.
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?
No guidance on when to use this tool versus alternatives such as fo_list_promotions or fo_search_products. No exclusions or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all product catalogs you have access to. Returns catalog IDs (cid) needed for product searches.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| pageSize | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full burden. It states 'list all product catalogs you have access to' but does not disclose pagination behavior, data freshness, or rate limits. The parameters 'page' and 'pageSize' hint at pagination but are not explained.
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 sentences long, contains no filler, and each sentence adds essential information: what the tool does and why it is useful.
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 listing tool, the core purpose and return value are covered. However, missing details about pagination handling and output structure (since no output schema) leave gaps for an agent.
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 0% and the description does not mention the two parameters (page, pageSize) at all. With no parameter explanations, the description adds no value beyond the schema field names.
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 all accessible product catalogs and explains the return value (catalog IDs) and its purpose for subsequent product searches. This distinguishes it from sibling tools like fo_search_products and fo_list_advertisers.
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 that the tool should be used before product searches to obtain catalog IDs, providing clear context. However, it does not explicitly mention when not to use it or compare it to alternatives like fo_search_products_full.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch active promotions and coupons from FlexOffers. Filter by advertiser, category, promo type, or date range. Use couponsOnly=true for coupon codes only.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| names | No | Search by promotion name | |
| endDate | No | Filter promotions expiring before this date (YYYY-MM-DD) | |
| pageSize | No | Max 1000 | |
| startDate | No | Filter promotions active after this date (YYYY-MM-DD) | |
| categoryIds | No | Comma-separated category IDs | |
| couponsOnly | No | Only return promotions with coupon codes | |
| minDollarOff | No | Minimum $ discount | |
| advertiserIds | No | Comma-separated advertiser IDs | |
| minPercentageOff | No | Minimum % discount | |
| promotionalTypeIds | No | Comma-separated promo type IDs (get IDs from fo_get_promotion_types) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It states the tool fetches data, implying a read operation, but does not disclose potential side effects, authentication needs, rate limits, or pagination behavior beyond the schema. The description lacks depth on behavioral traits.
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 sentences, front-loaded with the primary action, and contains no superfluous information. Every phrase contributes to clarity and conciseness.
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 11 parameters and no output schema, the description explains filtering options but omits details on pagination, result ordering, or the structure of the response. For a list tool, this leaves gaps in completeness, though the schema covers parameter ranges (e.g., max 1000).
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 91%, placing the baseline at 3. The description adds value by clarifying the purpose of couponsOnly and highlighting key filters (advertiser, category, promo type, date range), which helps the agent understand parameter usage beyond schema names.
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?
Clearly states it fetches promotions and coupons from FlexOffers with filtering options. The verb 'Fetch' and resource are specific, but no explicit differentiation from sibling tools like fo_list_advertisers or fo_get_promotion_types, though the context makes it clear.
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?
Provides a usage hint for couponsOnly=true and suggests using fo_get_promotion_types for promo type IDs. However, it does not specify when to avoid this tool or mention alternatives, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search FlexOffers product catalog. Requires at least one of: cid (catalog ID), name, manufacturer, or UPCorEANs. Returns lightweight product rows.
| Name | Required | Description | Default |
|---|---|---|---|
| MPN | No | Manufacturer Part Number | |
| cid | No | Catalog ID (from fo_list_catalogs) | |
| name | No | Product name search | |
| page | No | ||
| Country | No | ||
| maxPrice | No | ||
| minPrice | No | ||
| pageSize | No | Max 500 | |
| UPCorEANs | No | Comma-separated UPC or EAN codes | |
| manufacturer | No | Filter by manufacturer/brand |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It indicates the tool returns lightweight product rows and requires certain parameters, but it does not discuss side effects, authentication needs, rate limits, or pagination behavior. The description adds some value by specifying the required parameter condition.
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 concise with two sentences that front-load the tool's purpose and key requirement. Every word contributes to understanding, with no redundant 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?
Given the tool has 10 parameters and no output schema or annotations, the description provides minimal context about search behavior, pagination (page, pageSize), price filters, or return format. It covers the essential constraint (required parameters) but lacks completeness for a complex search 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 description coverage is 60%, which is moderate. The description groups some parameters (cid, name, manufacturer, UPCorEANs) as required together, adding context beyond the schema. However, it does not elaborate on the meaning or usage of the remaining six parameters, which are only described in the 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 clearly states it searches the FlexOffers product catalog and specifies the required input categories (cid, name, manufacturer, or UPCorEANs). It also mentions the output type ('lightweight product rows'), distinguishing it from the full version sibling. However, it does not explicitly contrast with siblings like fo_search_products_full.
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 provides guidance on when to use the tool by stating the requirement for at least one of the listed parameters. However, it does not explicitly exclude any scenarios or mention alternatives such as fo_search_products_full for more complete results.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search FlexOffers product catalog with full details including discounts and sale flags. Slower than fo_search_products but richer data.
| Name | Required | Description | Default |
|---|---|---|---|
| cid | No | Catalog ID (from fo_list_catalogs) | |
| name | No | Product name search | |
| page | No | ||
| Country | No | ||
| pageSize | No | Max 500 | |
| Max_discount | No | Maximum discount % | |
| manufacturer | No | Filter by manufacturer/brand | |
| min_discount | No | Minimum discount % |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavioral traits. It mentions the tool is 'slower' and provides 'richer data', but does not detail the extent of slowness, rate limits, or what other fields are in 'full details'. It adds some value but lacks comprehensive transparency.
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 concise with two sentences, front-loading the action and outcome. Every phrase is functional: 'Search FlexOffers product catalog with full details including discounts and sale flags' covers purpose and key features. No unnecessary words.
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?
Despite having 8 parameters and no output schema, the description is sparse. It does not explain what 'full details' entails, lacks guidance on parameter combinations or defaults, and doesn't address pagination or result handling. The missing behavioral and parameter context makes it incomplete for safe invocation.
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 75%, so baseline is 3. The description does not add any parameter-specific information beyond the overall purpose. It fails to compensate for the two parameters (page, Country) that lack schema descriptions, limiting the agent's understanding of how to invoke the tool correctly.
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 verb 'Search' and the resource 'FlexOffers product catalog'. It specifies that it provides 'full details including discounts and sale flags', and explicitly distinguishes the tool from its sibling 'fo_search_products' by noting it is slower but richer, ensuring the agent can select the right tool.
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 provides guidance on when to use this tool: when richer data (discounts, sale flags) is needed and speed is less critical, as it notes 'Slower than fo_search_products but richer data'. However, it does not specify when to avoid using it or mention any prerequisites, missing some explicit guidance.
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.
v1.0.0fo_count_productsfo_export_reportfo_generate_deeplinkfo_get_categoriesfo_get_featured_advertisersfo_get_payment_detailsfo_get_payment_summaryfo_get_promotion_typesfo_list_advertisersfo_list_cardsfo_list_catalogsfo_list_promotionsfo_search_productsfo_search_products_fullScored across 14 tools
Each tool serves a distinct purpose: counting vs. searching products, listing vs. getting details, reports vs. payment summaries. No two tools have overlapping functionality.
All tools use a consistent 'fo_' prefix followed by a clear verb_noun pattern (e.g., count_products, export_report, generate_deeplink, get_categories). The pattern is uniform and predictable.
With 14 tools covering key areas like products, reports, payments, promotions, and advertisers, the count is well-scoped for the FlexOffers affiliate domain—neither too sparse nor overloaded.
The tool set comprehensively covers the primary operations: product search/count, advertiser listing, link generation, report export, payment details, promotions, and categories. No obvious gaps for standard affiliate tasks.
MCP server connecting AI agents to 100+ apps (Gmail, Slack, Notion, GitHub) via one-click OAuth.
Hosted MCP server connecting AI assistants to 9,000+ apps and 40,000+ actions via Zapier.
Automate 1,000+ services from any MCP-compatible AI agent: build Applets, run actions and queries.
Let AI agents query data and act across all your business apps via MCP.
