Checks whether an AI agent may earn money on a platform (AI content rules, bot/API access, KYC, fees, payout minimums, who handles VAT, ban reasons) with sources and check dates. Free checks; no legal or tax advice.
Scored across 5 tools
The five tools map to a clear decision funnel (overview → recommendation → verdict → facts → plan), and descriptions explicitly state when to use each. However, can_i_earn_here and get_platform partially overlap since both surface rules and ban reasons, so an agent could occasionally hesitate between the verdict tool and the facts tool.
list_platforms, get_platform, and get_plan follow a clean verb_noun pattern. But can_i_earn_here is a natural-language question and recommend is a bare verb, so the set mixes conventions even though the intent of each name remains readable.
Five tools is well-scoped for a niche earning-platform advisory server. Each tool earns its place in the discovery-to-plan workflow with no filler or redundancy.
The surface covers the full lifecycle: browsing platforms, getting a recommendation, checking eligibility, retrieving sourced facts, and fetching an executable plan. There is no tracking/update tool for saved plans, but that is a minor gap given the advisory nature.
Use before automating anything on a platform. Returns a verdict (ja/bedingt/unklar/nein, traffic light) whether an agent-run setup with AI content can earn there from a given country, the top ban reasons, documented costs of common mistakes (risk_without_plan, with sources), what the optional paid plan adds and a price-vs-cost calculation (why_pay, incl. when not to buy). Free. No legal or tax advice; never use it to bypass KYC or platform rules.
| Name | Required | Description | Default |
|---|---|---|---|
| country | No | ISO-3166 alpha-2 country of the human owner, default DE | |
| platform | Yes | Platform id | |
| automated | No | Will the agent operate the account/uploads automatically? default true | |
| ai_content | No | Will the offering contain AI-generated content? default true |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does disclose meaningful traits: it is free ("Free"), it is advisory only (no legal/tax advice), it returns sourced cost data, and it flags "when not to buy" the paid plan. It does not discuss caching, rate limits, or freshness of the verdict, which is the main remaining gap for a zero-annotation tool.
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 usage instruction is front-loaded and the whole definition fits in three sentences. It is dense with parentheticals and inline field names ("risk_without_plan", "why_pay") that add slight clutter, but each clause conveys real information about outputs rather than padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description must explain returns and it does: the four verdict values with a traffic-light framing, ban reasons, sourced mistake costs, plan value, and the price-vs-cost verdict. Covers what an agent needs to decide and call the tool, though it omits how trustable/sourced the verdict input data is.
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%, so country, platform, automated and ai_content (with defaults) are already documented. The description only re-frames them collectively ("agent-run setup with AI content ... from a given country") without adding format, allowed values, or interaction details beyond the schema. Baseline 3 is appropriate.
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 action ("Returns a verdict ... whether an agent-run setup with AI content can earn there from a given country") and enumerates the payload: verdict, ban reasons, documented mistake costs, plan value, price-vs-cost calculation. This is clearly an eligibility/verdict check, distinguishable from list_platforms or get_platform. It never names a sibling tool explicitly, so it stops short of full differentiation.
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?
"Use before automating anything on a platform" gives an explicit trigger condition, and the closing sentence sets boundaries ("No legal or tax advice; never use it to bypass KYC or platform rules"). However, it never points to an alternative tool or says when another sibling such as recommend would be the better call.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use when you decided on a platform and want the executable step-by-step plan (bot/human split, human minutes, order, checklist against ban reasons, DE tax/payout notes with sources). Paid: 0.25 USD per plan; payment via x402 (USDC on Base) over HTTP: this tool returns the price, the x402 payment requirement and a free preview; pay and fetch the full plan with GET /plans/{platform} + PAYMENT-SIGNATURE header. Plans exist for: adobe-stock, etsy, spreadshirt, redbubble, gumroad, apify.
| Name | Required | Description | Default |
|---|---|---|---|
| platform | Yes | One of: adobe-stock, etsy, spreadshirt, redbubble, gumroad, apify | |
| preview_only | No | Only return the free preview |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so: exact price (0.25 USD/plan), payment rail (x402, USDC on Base), what this call returns (price, payment requirement, free preview), and how to obtain the full plan (GET /plans/{platform} with PAYMENT-SIGNATURE). Cost and payment/auth prerequisites are exactly the behavioral facts an agent needs before calling.
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-loaded with the usage trigger, then the value proposition, then payment mechanics, then valid platforms. It is dense but every clause carries information the agent needs; nothing is redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, yet the description compensates by stating precisely what is returned (price, x402 requirement, free preview) and how to get the full artifact. Combined with the enumerated platform set and payment path, an agent has everything required to invoke and follow up 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% with only 2 simple params, so the schema already documents both. The description reinforces the preview concept ('returns ... a free preview') and re-lists the valid platforms, but adds no syntax or constraint detail beyond the schema. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific resource ('executable step-by-step plan') plus its contents (bot/human split, human minutes, order, ban-reason checklist, DE tax/payout notes) and the trigger ('you decided on a platform'). This is clearly separable from siblings like recommend, get_platform, or list_platforms, which operate at earlier decision stages.
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 opening 'Use when you decided on a platform' gives an explicit precondition that implicitly excludes the earlier-stage siblings (recommend/can_i_earn_here) without naming them. It also explains the paid flow and enumerates which platforms have plans. It stops short of explicitly naming the alternative tools to use beforehand.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use when you already picked a platform and need all sourced facts: rules, human steps, KYC, fees, payout minimum and methods, VAT/merchant of record, known ban reasons, sources, check date. Free. No legal or tax advice.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Platform id, one of: adobe-stock, etsy, spreadshirt, redbubble, gumroad, polar, lemon-squeezy, apify, fiverr, upwork, amazon-partnernet-de, youtube, superteam-earn, shutterstock, pond5, ko-fi, patreon, stripe-mpp, x402, hugging-face, github-sponsors, product-hunt, smithery, glama, medium-partner |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does disclose meaningful traits: it is free, it returns sourced facts with a check date, and it explicitly disclaims legal/tax advice. It doesn't state whether the call is read-only or note rate limits, but for a clearly-named lookup this is solid coverage.
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-loaded with the usage condition, then a compact list of what is returned. Every phrase carries information; the enumerated list is dense but appropriate given there is no output schema to convey the return shape.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description usefully enumerates the returned facts, which is exactly what an agent needs here. One param fully documented, usage precondition stated, disclaimer included — little is missing for a single-id lookup tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single 'id' parameter already enumerates all valid platform ids, so the schema does the heavy lifting. The description adds no format or constraint detail beyond it, which is the expected baseline for fully documented params.
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 ('get') and resource ('platform'), then enumerates the exact payload (rules, human steps, KYC, fees, payout minimum, ban reasons, sources, check date). The phrase 'Use when you already picked a platform' implicitly contrasts with list_platforms, though no sibling is named outright.
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?
'Use when you already picked a platform' gives a clear precondition that separates this from list_platforms or recommend. However, it never explicitly names those alternatives or states when-not to use it, leaving the routing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use when you need an overview of platforms where an AI agent and its human can earn money, filtered by category. Returns per platform: AI-content rule, automation rule, merchant-of-record status, payout minimum, estimated human minutes. Free. No legal or tax advice.
| Name | Required | Description | Default |
|---|---|---|---|
| kategorie | No | Optional category filter, e.g. stock_media, print_on_demand, merchant_of_record, freelance, agent_payments |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does reasonably well: it enumerates the fields returned per platform (AI-content rule, automation rule, merchant-of-record status, payout minimum, estimated human minutes), declares the tool is free, and disclaims legal/tax advice. It omits pagination or result-size behavior, but for a free read-only list this is solid disclosure.
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 tight sentences, front-loaded with the usage trigger, then the return payload, then cost and disclaimer. Nothing is padded, though the final two fragments are terse enough that they read more as bullet residue than prose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description's enumeration of returned fields is doing necessary work, and it covers cost and legal scope. Given a one-optional-parameter list tool with no annotations, the entry is nearly complete; only pagination/volume expectations are absent.
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%, and the single category parameter is fully documented in the schema with examples. The description only restates that results are "filtered by category" without adding format or matching semantics, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource — listing earning platforms for an AI agent and its human — plus the scope (filtered by category). It is clearly distinguishable from get_platform in intent, though it never names that sibling or any other to sharpen the boundary.
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?
"Use when you need an overview of platforms" gives a usable trigger condition and implies the category filter's role. However, it never says when NOT to use it, nor points to get_platform or recommend for the single-platform or recommendation cases, leaving the routing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use when your goal is to earn money with a small budget and limited human time and you have not chosen a platform yet. Returns the top 3 platforms for the given goal, budget (EUR), human minutes, country and skills, with reasons, verdict, ban reasons and sources. Platforms with verdict "nein" are excluded and listed with the reason. Ranking ignores whether a paid plan exists. Free. No legal or tax advice.
| Name | Required | Description | Default |
|---|---|---|---|
| goal | Yes | What you want to earn money with, e.g. "sell ai images", "publish a scraper" | |
| skills | No | e.g. images, video, design, writing, code, scraping, templates | |
| country | No | ISO-3166 alpha-2 country of the human owner, default DE | |
| automated | No | Will the agent operate the account automatically? default true | |
| ai_content | No | Will the offering contain AI-generated content? default true | |
| budget_eur | No | Available money in EUR, default 20 | |
| human_minutes | No | Human minutes available for setup, default 60 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses that exactly 3 platforms are returned with reasons, verdict, ban reasons and sources, that 'nein' verdict platforms are excluded and listed with a reason, that ranking ignores paid-plan existence, that it is free, and that it gives no legal/tax advice. It does not mention auth requirements, latency or rate limits, so not a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads the usage condition, then the return shape, then edge-case behavior and disclaimers. Dense and nearly every clause earns its place, though the middle sentence packs a lot of clauses that could be split for faster scanning.
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 exists, and the description compensates by describing the return payload (3 platforms, reasons, verdict, ban reasons, sources) and the exclusion behavior for 'nein' verdicts. Combined with full schema coverage, an agent has everything needed to call and interpret the 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 100%, so the schema already documents every parameter including defaults (country DE, budget 20, human_minutes 60, automated/ai_content true). The description restates budget (EUR), human minutes, country and skills without adding syntax or format meaning beyond the schema, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource (returns top 3 earning platforms) and scopes it to an un-chosen-platform decision, which distinguishes it from get_platform, list_platforms and can_i_earn_here. An agent can tell what it gets back without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit when: small budget, limited human time, and no platform chosen yet. It implies the when-not (already chosen a platform) but does not name the sibling alternatives (get_platform, get_plan) an agent should switch to, so it falls short of a full 5.
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.
can_i_earn_hereget_planget_platformlist_platformsrecommend
Add one secure layer between your agents and this server.