Allows the currency take-home calculator to use Payoneer as an international-account provider, converting multi-platform, multi-currency earnings into a single total using live exchange rates and Payoneer's fee structure.
Allows the currency take-home calculator to use Wise as an international-account provider, converting multi-platform, multi-currency earnings into a single total using live exchange rates and Wise's fee structure.
An MCP server exposing three free platform-income calculators from Platform Income Utils as tools any MCP-compatible AI agent can call directly.
All three tools reuse the exact same math as the live web pages, so an agent's answer never drifts from what a human sees on platformincome.com.
take_home_pay_calculatorTake-home pay after platform fees, optional ~2% currency-conversion cost, and optional
per-withdrawal transaction fees, across 18 gig/creator/freelance/ecommerce platforms.
Mirrors take-home-pay.html.
list_take_home_platformsLists every platform id/name/fee structure take_home_pay_calculator accepts.
platform_payout_calendarFor one or more platforms, returns the next expected payout-initiated date and
bank-arrival date (payout date + regional transfer delay, pushed off weekends).
Fetches live data from the same source as
platform-payout-calendar.html,
so newly-added platforms or corrected schedules show up automatically with no server
redeploy needed.
list_payout_platformsLists every platform id/name/verification-status platform_payout_calendar accepts
(live from the same data source).
benefits_safety_net_calculatorFor gig workers, freelancers, creators, sellers, and hosts with no employer benefits,
calculates a monthly self-funded health + retirement set-aside (default 5%, split
60/40), plus an optional emergency buffer. Mirrors
benefits-safety-net.html.
list_benefits_countriesLists every country benefits_safety_net_calculator accepts, with its currency.
currency_takehome_calculatorThe genuine differentiator tool: combine earnings from several platforms, each in its
own currency, into one converted total via whichever international-account provider
(Wise, Payoneer, Airwallex, etc.) nets the most money for your country — using live
exchange rates. Most free take-home-pay calculators only handle one platform and one
currency at a time; this one is built specifically to answer "I earn from five
platforms in three currencies, what do I actually end up with?" Mirrors
currency-takehome.html.
list_currency_takehome_countriesLists every country code currency_takehome_calculator accepts.
list_platformtaxhub_toolsLists every other free calculator on platformincome.com, including the ones not wrapped as their own MCP tool here (mileage deduction, tax deadline clock, fees comparison, and more) — so an agent can point a user to the right free tool even when the question doesn't fit one of the tools above.
Related MCP server: agentforge
npx platformtaxhub-mcpOr add it to your MCP client config (Claude Desktop, Claude Code, etc.):
{
"mcpServers": {
"platformtaxhub": {
"command": "npx",
"args": ["-y", "platformtaxhub-mcp"]
}
}
}No API key or account required — every tool here is free, matching the free tools on platformincome.com.
npm install
npm run build
npm startsrc/data.ts holds the platform-fee table and country/currency tables, ported
verbatim from the corresponding <select> options and JS objects in
take-home-pay.html and benefits-safety-net.html. If those change on the live
site, update data.ts to match. platform_payout_calendar has no static table to
maintain — it always fetches live from the same n8n webhook the calendar page uses.
MIT — see the platformincome.com free tools this wraps for the calculators themselves; this package is just the MCP interface to them.
For gig workers, freelancers, creators, sellers, and hosts with no employer-provided benefits, calculates a monthly set-aside for a self-funded health + retirement safety net (default 5% of income, split 60% health / 40% retirement), plus an optional emergency buffer. Mirrors platformincome.com/benefits-safety-net.html exactly. Call list_benefits_countries first if you don't already know a country's exact name.
| Name | Required | Description | Default |
|---|---|---|---|
| icp | No | Which kind of platform earner this is for — only changes the wording of the per-unit breakdown, not the math. | gig |
| country | Yes | Country name exactly as returned by list_benefits_countries, e.g. 'United States', 'Nigeria', 'India'. | |
| monthlyIncome | Yes | Monthly platform income/earnings target. | |
| setAsidePercent | No | Total % of monthly income to set aside. Defaults to 5% (the recommended baseline), split 60% health / 40% retirement. | |
| emergencyPercent | No | Optional additional % of monthly income for an emergency buffer, on top of the baseline set-aside. Defaults to 0 (off). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does disclose the core calculation behavior: default 5% set-aside, 60/40 health/retirement split, optional emergency buffer, and exact replication of the reference page. It doesn't state the return shape (no output schema exists), but for a calculator the formula and constraints are the main behavioral facts.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences cover audience, behavior, defaults, source, and a prerequisite, with no filler. The most decision-relevant information (audience + calculation) is front-loaded.
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 five-parameter calculator with no annotations and no output schema, the description covers the use case, formula, exact reference behavior, and a country-name prerequisite. The only notable gap is the lack of an explicit description of the return format, so it isn't a perfect 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description restates the default split and optional buffer, but those details already appear in the setAsidePercent and emergencyPercent schema descriptions, so it adds little beyond 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 states a specific verb and resource: it 'calculates a monthly set-aside for a self-funded health + retirement safety net', names the target audience, and gives the default formula. This clearly separates it from sibling calculators like take_home_pay_calculator or platform_payout_calendar.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly scopes when to use it: for workers with no employer-provided benefits, and it gives a required prerequisite ('Call list_benefits_countries first if you don't already know a country's exact name'). It doesn't call out when-not-to-use or alternatives, so it misses the top criterion for a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The one tool that answers 'I earn from several platforms, in several currencies — how much do I actually end up with in my own currency?' Give it a list of platform earnings (each with its own currency and platform fee %), plus your country and target currency, and it converts and combines them all through whichever international-account provider (Wise, Payoneer, Airwallex, etc.) nets you the most money — using live exchange rates, not estimates. This aggregation-across-platforms capability is not something other free take-home-pay calculators do; most only handle one platform and one currency at a time. Mirrors platformincome.com/currency-takehome.html exactly. Call list_currency_takehome_countries first if you don't know a country's 2-letter code.
| Name | Required | Description | Default |
|---|---|---|---|
| country | Yes | 2-letter country code you'll receive the money in, e.g. 'US', 'NG', 'IN'. Call list_currency_takehome_countries for the full list. | |
| platforms | Yes | One entry per platform/income source you want combined into a single total. | |
| targetCurrency | Yes | 3-letter currency code to convert everything into, e.g. 'USD', 'NGN', 'EUR'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden, and it does so well: it discloses that the tool uses live exchange rates rather than estimates, selects the international-account provider that nets the most money, and mirrors a specific web page exactly. It could add more about return format or failure behavior, but the core mechanics are clearly 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 longer than typical but each part earns its place: the user question, the input components, the provider-selection behavior, the differentiator, the mirror reference, and the prerequisite call. It is front-loaded with the core value proposition, though some phrasing is promotional and could be trimmed.
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 there is no output schema, the description does well to convey the expected outcome ('how much do I actually end up with') and provides essential invocation context such as the country-code prerequisite and the live-rate/provider behavior. It does not specify the exact response structure, which is a minor gap for a calculator tool, but overall it is sufficient for selecting and invoking the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds useful framing about platform fees being deducted before conversion and the goal of targeting one currency, but it largely restates what the schema already documents about country, targetCurrency, and platforms. It does not add deeper semantics beyond 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 opens with a concrete user question and clearly states the tool's function: accepting multiple platform earnings in different currencies and converting/combining them into one target currency total. It also distinguishes itself from other take-home calculators by emphasizing its aggregation across platforms and currencies, which separates it from siblings like take_home_pay_calculator.
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 clear context for when to use this tool: when you have multiple platforms/currencies to combine, and it explicitly notes that most other calculators handle only one platform and one currency. It also gives a concrete prerequisite by telling users to call list_currency_takehome_countries first if they lack a country code, though it does not explicitly name a sibling to use for single-platform cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns every country id (and its currency) supported by benefits_safety_net_calculator.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It states that the tool returns every country id and currency, which signals a read-only listing behavior and the lack of filtering. However, it does not describe response shape details, ordering, potential errors, or any limitations, which keeps this at a mid-range score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It immediately states the action, the resource returned, and the parent calculator context.
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 this is a simple zero-parameter list tool with no output schema, the description clearly states what the agent gets back: every country id and its currency. A minor gap is not specifying whether ids are country codes or human-readable names, but this is sufficient for selecting and invoking the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the description needs to explain no inputs. The description correctly makes no parameter claims and instead focuses on the output, matching the baseline for zero-parameter tools.
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 uses a specific verb ('Returns') with a clear resource ('every country id (and its currency)') and links it to the exact calculator tool, benefits_safety_net_calculator. This makes it easy to distinguish from sibling list tools like list_take_home_platforms and list_payout_platforms.
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 'supported by benefits_safety_net_calculator' implies the tool is for retrieving countries relevant to that calculator, which gives context for when to use it. However, it does not explicitly mention alternative list tools or state when not to use this one, so the guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns every country code/name currency_takehome_calculator accepts, used to filter which international-account providers (Wise, Payoneer, etc.) are available.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It explicitly states that the tool returns data and describes what it returns, implying a read-only safe operation. It does not mention pagination, sorting, or failure modes, but for a simple list tool this is not a major gap.
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, tightly written sentence that front-loads the primary action and result, followed by the use case. No redundant words or 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?
No output schema is provided, so the description must explain what is returned. It does so ('country code/name') and explains the purpose. It could specify the exact return shape (e.g., array of objects) but for a simple list tool the description is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline score is 4 per the rubric. The description adds no parameter info, but none is needed. It does clarify the output is country code/name, which helps set expectations.
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 ('Returns') and resource ('every country code/name currency_takehome_calculator accepts'), and ties it to a concrete use case (filtering available international-account providers). It distinguishes itself from sibling tools by naming the exact calculator it serves.
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 clear context for when to use the tool ('used to filter which international-account providers... are available'). It does not explicitly name alternatives or state when not to use it, but the intended workflow is obvious for a zero-parameter list tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns every platform id and name currently tracked by platform_payout_calendar, live from platformincome.com's data source, including which ones have no verified schedule yet.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden and does disclose that data is live from platformincome.com, returns every tracked platform, and includes platforms with no verified schedule. It does not mention response shape or potential remote-fetch latencies, but these are minor for a simple read-only enumeration.
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 delivers the core action, the exact data returned, the source, and the notable edge case (no verified schedule). There is no filler or redundant restatement of the title.
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 list tool with no output schema, the description tells the agent what data will be returned and that unscheduled platforms are included. Slightly more detail on the output shape or how to obtain schedule details could help, but nothing essential is missing for selecting and invoking this 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?
The tool has zero parameters and schema coverage is 100%, so there are no parameter ambiguities. The description adds no parameter info because none is needed; baseline for 0-param tools is 4.
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 states a specific verb ('Returns') and resource ('every platform id and name currently tracked by platform_payout_calendar'), plus the live origin and special inclusion of platforms without verified schedules. This clearly differentiates it from sibling 'platform_payout_calendar' and 'list_take_home_platforms'.
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 makes clear it returns identifier data from the payout calendar, implying use when a caller needs the set of tracked payout platforms. It does not explicitly name alternatives or exclusion conditions (e.g., use list_take_home_platforms for take-home platforms), so guidance is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the full list of platformincome.com's free calculators, including ones not exposed as their own MCP tool here (mileage deduction, tax deadline clock, fees comparison, and more). Use this when a user's question is about platform income but doesn't fit take_home_pay_calculator, platform_payout_calendar, benefits_safety_net_calculator, or currency_takehome_calculator.
| 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 burden. It discloses that the tool returns a list of free calculators and that some listed tools are not exposed as MCP tools, which is useful behavioral context. However, it doesn't describe the output format (e.g., plain list vs. structured data) or whether the list is static or fetched live, leaving some behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core purpose, followed by concrete examples and explicit routing guidance. Every sentence earns its place with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list tool, the description is nearly complete: it states what the list contains, gives examples, and explains when to use it. The only minor gap is the lack of detail about the return format, but given the tool's simplicity and the absence of an output schema, this is a small omission.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is no parameter semantics burden. The description adds value by explaining what the returned list contains and how it relates to sibling tools, which is more than the empty schema provides. Baseline 4 for zero params 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 clearly states the tool returns the full list of platformincome.com's free calculators, including tools not exposed as MCP tools. It names specific examples (mileage deduction, tax deadline clock, fees comparison) and explicitly distinguishes it from sibling calculator tools, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance: 'Use this when a user's question is about platform income but doesn't fit' the four named sibling calculators. This directly routes the agent to the correct tool and away from alternatives, which is exactly what usage guidelines should do.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns every platform id, display name, category, and fee structure supported by take_home_pay_calculator.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. It only describes the output contents, not whether the call is read-only, requires authentication, paginates, or orders results. The verb 'Returns' weakly implies no side effects but is not explicit.
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, tightly worded sentence that front-loads the action and output fields. Every word earns its place with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless list tool, the description adequately covers what data is returned and the source calculator. It does not mention ordering or whether the list is exhaustive across regions, but these are minor gaps for a simple listing operation with no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so no parameter semantics are needed. The description adds nothing about parameters, but the baseline of 4 applies because there is nothing to explain.
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 ('Returns'), the exact resource ('every platform id, display name, category, and fee structure'), and scopes it to take_home_pay_calculator. This clearly distinguishes it from sibling tools like list_payout_platforms by tying it to the take-home calculator context.
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: an agent would use this when it needs the list of platforms supported by take_home_pay_calculator. However, it does not explicitly contrast this with alternatives such as list_payout_platforms or provide when/when-not conditions, leaving some inference required.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Given one or more platforms, returns when their next payout is expected to be initiated and when it should actually arrive in your bank account (payout date plus regional bank-transfer delay, pushed off weekends). Mirrors platformincome.com/platform-payout-calendar.html exactly, using the same live data source. Call list_payout_platforms first if you don't already know a platform's id.
| Name | Required | Description | Default |
|---|---|---|---|
| month | No | Month to check, as YYYY-MM (e.g. '2026-10'), for looking up a specific past or future month. If omitted, the tool instead returns each platform's actual NEXT upcoming payout (rolling forward past any already-happened date in the current month). | |
| region | No | Region, used for the default bank-transfer delay when a platform doesn't publish its own. Defaults to 'int' (International, 5 days). | int |
| platformIds | Yes | One or more platform ids, e.g. ['youtube', 'upwork', 'airbnb']. Call list_payout_platforms to see all valid ids. |
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 behavior beyond a simple 'returns dates': actual arrival is computed with regional delay and weekends pushed off, and it mirrors a live data source. It does not cover error handling or rate limits, but for a read-only lookup the key behaviors are 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 three sentences with no filler. It front-loads the core purpose, adds a source-mirroring note, and closes with an actionable prerequisite. Every sentence 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?
Without an output schema, the description clearly explains what the tool returns: payout initiation and actual arrival dates. Combined with the fully described input schema, an agent has enough to call the tool correctly. It could be more explicit about response shape or multi-platform behavior, but the prose covers the essential return semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, giving a baseline of 3. The description adds meaning beyond the schema by explaining that the arrival date includes regional bank-transfer delay and weekend adjustment, and by telling the agent to call list_payout_platforms for valid ids. This enriches the platformIds and region parameters without repeating the schema verbatim.
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 specific verb and resource: given platforms, it returns next payout initiation and actual arrival dates, including regional bank-transfer delay and weekend handling. It also distinguishes itself from sibling tools by focusing on payout scheduling rather than benefits or take-home pay calculations.
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 gives clear context on when to use the tool and provides a prerequisite: call list_payout_platforms first if the platform id is unknown. It does not explicitly name alternatives or exclusions, but the usage context is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate actual take-home pay after platform fees, optional currency-conversion cost (~2%), and optional per-withdrawal transaction fees, for 18 gig/creator/freelance/ecommerce platforms (Uber, YouTube, Upwork, Etsy, Airbnb, and more). Mirrors platformincome.com/take-home-pay.html exactly. Call list_take_home_platforms first if you don't already know a platform's id.
| Name | Required | Description | Default |
|---|---|---|---|
| period | No | Period to express the result in. grossAmount is always treated as a MONTHLY figure; period only changes the display breakdown. | month |
| currency | No | 3-letter currency code, e.g. USD, GBP, EUR, NGN, INR. Defaults to USD. | USD |
| platform | Yes | Platform id, e.g. 'uber-lyft', 'youtube', 'upwork'. Call list_take_home_platforms to see all valid ids. | |
| grossAmount | Yes | Gross monthly earnings, before any fees. | |
| includeTransactionFee | No | Add the platform's per-withdrawal transaction fee, where one applies (e.g. Uber Instant Pay, Upwork wire transfer). Ignored for platforms with no transaction fee. | |
| includeCurrencyConversion | No | Add an estimated 2% currency-conversion cost on top of the platform fee. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It is transparent about included costs, the ~2% conversion estimate, optional transaction fees, the exact 18-platform scope, and the fact that it 'Mirrors platformincome.com/take-home-pay.html exactly.' It does not explicitly state that the operation is read-only or side-effect-free, but the verb 'Calculate' plus calculator context makes that sufficiently clear.
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 sentences with no filler: the main purpose is front-loaded, the optional fee behavior is summarized, and the prerequisite lookup call is placed last. Every sentence contributes to correct invocation.
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 6-parameter tool with no output schema, the description covers the core calculation, fee options, platform scope, and the required lookup prerequisite. It does not describe the return shape or period breakdown, but the schema documents period behavior and the tool's purpose makes the output self-evident. Slightly more detail about the returned values would make it fully 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 coverage is 100%, so the baseline is 3. The description adds value beyond the schema by explaining the optional fee semantics (~2% conversion, per-withdrawal fees), the platform-id precondition, and the exact mirror target. It does not discuss period or currency, but those are already well documented 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 uses a specific verb and resource: 'Calculate actual take-home pay after platform fees, optional currency-conversion cost (~2%), and optional per-withdrawal transaction fees' for a defined set of 18 platforms. It differentiates itself from sibling tools by naming list_take_home_platforms and pinning behavior to a specific external page, making its role unmistakable.
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 gives clear context: this is the tool for computing take-home pay across specified platforms and optional fees. It also provides a concrete prerequisite, 'Call list_take_home_platforms first if you don't already know a platform's id.' It does not explicitly state when to prefer another calculator sibling, such as currency_takehome_calculator, so it falls short of a full when/when-not contrast.
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.3.0benefits_safety_net_calculatorcurrency_takehome_calculatorlist_benefits_countrieslist_currency_takehome_countrieslist_payout_platformslist_platformtaxhub_toolslist_take_home_platformsplatform_payout_calendartake_home_pay_calculatorScored across 9 tools
Each calculator targets a distinct money question (single-platform take-home, multi-currency aggregation, payout timing, benefits set-aside) and each has a dedicated list helper. The main possible confusion is between take_home_pay_calculator and currency_takehome_calculator, but their single-platform vs. multi-platform scope is clearly separated in the descriptions.
List helpers consistently use the list_ prefix, and three of four calculation tools use the *_calculator suffix. Minor deviations like platform_payout_calendar (calendar rather than calculator) and the inconsistent take_home vs. takehome spelling keep it from a 5.
Nine tools is well-scoped for a niche calculator hub: four calculators, four matching lookup tools, and one meta directory. Every tool has a clear role and none feel redundant.
The core workflows are fully supported: each calculator has a prerequisite list tool, and the meta list routes other platform-income questions. The explicit mention of unexposed calculators (mileage deduction, tax deadline clock) is a minor gap, but agents can work around it via list_platformtaxhub_tools.
Pay-per-use tool marketplace for AI agents. Search, price-check, and call APIs via MCP.
Hosted MCP server for live public-data APIs and Skills for AI agents.
44 calculators for AI agents: US tax, finance, business + an MCP engineering & security suite.
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
