Argentina data tools: dolar blue/MEP/CCL, INDEC inflation, feriados, CUIT/CBU, FX; x402 pay-per-call
Scored across 11 tools
Each tool targets a distinct resource: CBU, CUIT, phone, Argentine dollar quotes, holidays, inflation, generic FX, landing page generation, service info, paid API listing, and web audit. The only mild overlap is ar_dolar vs fx_rate (both return exchange rates), but the descriptions make the Argentine-specific vs generic fiat distinction clear. get_service_info and list_paid_apis also touch pricing but are clearly separated by purpose.
The set is predominantly snake_case, with a consistent ar_ prefix grouping the Argentina-specific utilities. Minor deviation: some tools are verb_noun (generate_landing_page, get_service_info, list_paid_apis) while others are noun-only (ar_cbu, fx_rate, web_audit), but all remain highly readable and predictable.
Eleven tools is a reasonable, well-scoped count. The surface is somewhat heterogeneous (a landing-page service bundled with Argentine regional utilities and a web auditor), but no tool feels redundant and each earns its place.
The landing-page domain covers generation, service description, pricing discovery, and page auditing, and the utility APIs are self-contained single-function tools. The main gap is the absence of a publish/deploy or order/checkout tool, so agents cannot complete the advertised 'published in 24 hours' workflow end-to-end within the server.
Validate an Argentine bank account number (CBU) or virtual account (CVU): checks both check digits offline and returns type, entity/branch codes, bank name for major banks and a formatted value. Send {cbu}. Nothing is stored. Paid tool: 0.01 USDC per call via x402 (USDC on Base, Polygon or Solana, no account or key). An unpaid call returns a payment-required result (isError, structuredContent with x402Version 2 and accepts); sign one of the accepts and retry the same call with the PaymentPayload in params._meta["x402/payment"]. Returns JSON text; the settlement is in result._meta["x402/payment-response"].
| Name | Required | Description | Default |
|---|---|---|---|
| cbu | Yes | 22-digit CBU or CVU |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly, idempotent, non-destructive and closed-world, yet the description adds substantial context: validation is offline, no data is stored, pricing (0.01 USDC per call across three chains, no account/key), the shape of a payment-required failure (isError, structuredContent with x402Version 2 and accepts), and where the settlement receipt lands (result._meta["x402/payment-response"]). This is exactly the kind of behavior an agent cannot infer from structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose and validation scope are front-loaded in the first sentence; the payment flow follows in the order an agent would encounter it (call, unpaid result, sign, retry, settlement). No filler sentences.
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, and the description fully covers the return shape (type, entity/branch codes, bank name for major banks, formatted value, JSON text) as well as the failure/retry path. An agent has everything needed to call it and handle both success and payment-required outcomes.
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 param already documents '22-digit CBU or CVU'. The description's 'Send {cbu}' and mention of 'Argentine bank account number (CBU) or virtual account (CVU)' add context but no format or syntax detail 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 (validate) and resource (Argentine CBU/CVU) and enumerates the outputs: check-digit verification, type, entity/branch codes, bank name, formatted value. This clearly distinguishes it from siblings like ar_cuit (tax ID) and ar_phone (phone numbers).
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 explicit operational guidance: send {cbu}, expects offline validation, nothing stored, and lays out exactly what to do on an unpaid call (sign an accepts entry and retry with the PaymentPayload in params._meta["x402/payment"]). It does not explicitly say when to choose this over sibling ar_cuit, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate an Argentine tax ID (CUIT/CUIL): checks length, prefix and modulo-11 check digit offline, and returns normalized and formatted values plus entity type (person/company). Send {cuit}. Nothing is stored. Paid tool: 0.01 USDC per call via x402 (USDC on Base, Polygon or Solana, no account or key). An unpaid call returns a payment-required result (isError, structuredContent with x402Version 2 and accepts); sign one of the accepts and retry the same call with the PaymentPayload in params._meta["x402/payment"]. Returns JSON text; the settlement is in result._meta["x402/payment-response"].
| Name | Required | Description | Default |
|---|---|---|---|
| cuit | Yes | CUIT or CUIL, with or without dashes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the safe/idempotent/closed-world profile, yet the description adds substantial non-obvious behavior: validation is performed offline, nothing is stored, cost is 0.01 USDC across three chains with no account required, and it precisely describes both the failure shape (isError plus structuredContent with x402Version 2 and `accepts`) and where settlement lands (`result._meta["x402/payment-response"]`). That is exactly the kind of detail annotations cannot carry.
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 purpose and return contract before the payment mechanics, and every sentence carries operative information (checks, storage, cost, retry protocol, settlement location). The payment segment is long but justified for an x402 tool; a slightly tighter phrasing of the retry steps would earn a 5.
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 still specifies the return content (normalized and formatted values, entity type, JSON text) and the metadata location for settlement. Combined with the fully specified payment/retry loop, an agent has everything needed to invoke and recover from the 402 path without guessing.
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 schema itself documents the `cuit` field as 'CUIT or CUIL, with or without dashes' with maxLength 60. The description's 'Send {cuit}' restates rather than enriches this, so baseline 3 applies — no added syntax guidance 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?
States a specific verb and resource ('Validate an Argentine tax ID (CUIT/CUIL)') and enumerates the actual checks performed (length, prefix, modulo-11 check digit) plus the return payload (normalized/formatted values, entity type). This makes it trivially distinguishable from siblings like ar_cbu or ar_phone, which cover different Argentine identifiers.
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 explicit invocation instruction ('Send {cuit}') and a complete conditional flow for the paid path: unpaid call returns a payment-required result, sign one of the `accepts`, retry with PaymentPayload in `_meta`. It does not name when to prefer a sibling (e.g. ar_cbu for bank codes), but the resource is narrow enough that misuse is unlikely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Current Argentine dollar quotes (ARS per USD): oficial, blue, bolsa (MEP), contado con liquidacion (CCL), mayorista, cripto and tarjeta, with buy/sell, spread, update time and the blue vs oficial gap. Send {} for all or {casa} for one. Source failure = no charge. Paid tool: 0.002 USDC per call via x402 (USDC on Base, Polygon or Solana, no account or key). An unpaid call returns a payment-required result (isError, structuredContent with x402Version 2 and accepts); sign one of the accepts and retry the same call with the PaymentPayload in params._meta["x402/payment"]. Returns JSON text; the settlement is in result._meta["x402/payment-response"].
| Name | Required | Description | Default |
|---|---|---|---|
| casa | No | Which quote; all by default | all |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnly/idempotent/openWorld, yet the description adds substantial context they can't convey: it is a paid x402 tool at 0.002 USDC per call, an unpaid call returns a payment-required result with structuredContent, the caller must sign an accepts entry and retry with PaymentPayload, source failures are not charged, and settlement appears in result._meta. This is exactly the beyond-annotation disclosure the dimension rewards.
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 purpose and selection rule are front-loaded in the first sentence, followed by the payment mechanics. It is dense and mostly earns its length, though the x402 retry/settlement explanation makes it longer than a typical read tool needs.
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 one-parameter read tool with no output schema, the description covers everything an agent needs: what is returned (JSON text), the rate fields, the payment requirement and failure modes, and where settlement lands. Nothing essential is missing.
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 parameter already has a full enum with a default, so the schema does the heavy lifting. The description adds only marginal value by clarifying the {} for-all vs {casa} for-one usage and the bolsa/MEP naming correspondence; 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 names a specific resource (current Argentine dollar quotes in ARS per USD) and enumerates every rate variant (oficial, blue, bolsa/MEP, CCL, mayorista, cripto, tarjeta). That level of specificity clearly separates it from generic siblings like fx_rate and from the other ar_* lookup 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?
"Send {} for all or {casa} for one" gives explicit invocation guidance and states the default behavior. It does not explicitly contrast itself with fx_rate or say when this alternative should be chosen over that one, 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.
Argentine national holidays (feriados, incl. puentes turisticos) for a year, and optionally a date check: weekday, holiday name, is_business_day, next business day, and date + N business days (skips weekends and holidays). Send {} for this year, {year}, or {date, add_business_days}. Source failure = no charge. Paid tool: 0.002 USDC per call via x402 (USDC on Base, Polygon or Solana, no account or key). An unpaid call returns a payment-required result (isError, structuredContent with x402Version 2 and accepts); sign one of the accepts and retry the same call with the PaymentPayload in params._meta["x402/payment"]. Returns JSON text; the settlement is in result._meta["x402/payment-response"].
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | Date to check, YYYY-MM-DD | |
| year | No | Year (default: current, or the year of date) | |
| add_business_days | No | Business days to add to date |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/openWorld, but the description goes well beyond them: it discloses the x402 paid-call flow, the exact shape of an unpaid response (isError with structuredContent containing x402Version 2 and accepts), how to retry with PaymentPayload in params._meta, that source failure incurs no charge, and where settlement appears. For a metered third-party API this is exactly the context 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?
Purpose and invocation modes are front-loaded in the first two sentences, which is the right ordering. The payment mechanics are dense and packed into one long block, but every sentence carries information the agent cannot get elsewhere; only minor tightening is possible.
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, and the description compensates by naming the returned fields (weekday, holiday name, is_business_day, next business day) plus the JSON-text return form and the payment-response location. Combined with the payment and retry semantics, nothing material is missing for correct 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 100%, so baseline is 3; the description earns an extra point by explaining the coupling between parameters — that year is implied by date and that add_business_days is only meaningful alongside date. That mode-combination logic is not fully spelled out 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?
States a specific resource (Argentine national holidays incl. puentes turisticos) and a specific secondary capability (date check returning weekday, holiday name, is_business_day, next business day, date + N business days). This is clearly distinguishable from all listed siblings (ar_cbu, ar_cuit, ar_dolar, ar_inflacion, ar_phone, fx_rate, etc.), none of which overlap.
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?
"Send {} for this year, {year}, or {date, add_business_days}" enumerates the three valid invocation shapes explicitly, which is unusually actionable guidance. It stops short of stating when not to use the tool or naming an alternative, but no sibling competes for this purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Argentine consumer price inflation from INDEC: latest monthly %, year-over-year %, last 12 months, and optionally the compounded cumulative inflation between two months with an amount adjusted for inflation (rent, salary, price updates). Send {} or {from: YYYY-MM, to: YYYY-MM, amount}. Source failure = no charge. Paid tool: 0.002 USDC per call via x402 (USDC on Base, Polygon or Solana, no account or key). An unpaid call returns a payment-required result (isError, structuredContent with x402Version 2 and accepts); sign one of the accepts and retry the same call with the PaymentPayload in params._meta["x402/payment"]. Returns JSON text; the settlement is in result._meta["x402/payment-response"].
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | Last month YYYY-MM (inclusive, default latest) | |
| from | No | First month YYYY-MM (inclusive) | |
| amount | No | Amount in ARS to adjust |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations: it declares the paid x402 model (0.002 USDC, chains accepted, no account/key needed), what an unpaid call returns (isError plus structuredContent with x402Version and accepts), exactly how to retry with the PaymentPayload in params._meta, and where settlement appears. It also discloses the "source failure = no charge" policy, which the agent could not infer from readOnly/idempotent hints alone.
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?
Purpose and modes come first, then payment mechanics, which is a sensible front-loading. It is dense but every sentence carries information: the payment flow and settlement location are operational necessities rather than filler. Marginally long, but not padded.
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 compensates by enumerating the returned data (monthly %, YoY %, 12-month series, cumulative adjustment) and pointing to result._meta for settlement. Only the exact JSON shape of the inflation payload is left implicit, which is a minor gap for a read-only 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%, so the baseline is 3, but the description adds real meaning: the empty-object form is the default latest reading, and the from/to/amount triple triggers compounded cumulative mode with the amount adjusted for inflation for use cases like rent or salary updates. It clarifies how the parameters interact rather than just restating their types.
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 (Argentine CPI from INDEC) and precisely what it returns: monthly %, YoY %, trailing 12 months, plus an optional compounded cumulative between two months with an ARS amount adjusted. This clearly separates it from siblings like ar_dolar, fx_rate or ar_cbu, which deal with exchange rates and other Argentine data rather than inflation indices.
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 both invocation shapes explicitly ("Send {} or {from, YYYY-MM, to, YYYY-MM, amount}"), which tells the agent how to choose between simple and cumulative mode. It also spells out the payment retry path. It does not explicitly exclude or compare itself with siblings such as fx_rate, but the domain difference is obvious from the purpose statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Parse and normalize an Argentine phone number written in any local style (011 15 1234-5678, +54 9 11..., 0351 4..., 15 prefix): strips trunk 0 and mobile 15, returns the 10-digit national number, E.164 in landline (+54) and mobile (+549) forms, a wa.me WhatsApp link and whether it is a mobile. Offline, nothing is stored. Send {phone}. Paid tool: 0.01 USDC per call via x402 (USDC on Base, Polygon or Solana, no account or key). An unpaid call returns a payment-required result (isError, structuredContent with x402Version 2 and accepts); sign one of the accepts and retry the same call with the PaymentPayload in params._meta["x402/payment"]. Returns JSON text; the settlement is in result._meta["x402/payment-response"].
| Name | Required | Description | Default |
|---|---|---|---|
| phone | Yes | Argentine phone number in any common format |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds substantial context beyond the annotations: it discloses that processing is offline with nothing stored, that the tool is paid (0.01 USDC via x402 on three chains, no account needed), exactly how the payment challenge appears in structuredContent, and where the settlement receipt lands in result._meta. Nothing here contradicts readOnlyHint/idempotentHint.
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 core purpose and output shape, then the payment mechanics. It is dense with parenthetical detail and the x402 paragraph is long, but every sentence carries operational information an agent needs before invoking a paid tool.
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 enumerates the return fields (10-digit national number, E.164 landline +54 and mobile +549 forms, wa.me link, is-mobile flag) plus the payment error and settlement paths. An agent has everything needed to call it and interpret both success and failure.
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 baseline is 3, and the description earns the bump by giving concrete accepted formats ('011 15 1234-5678', '+54 9 11...', '0351 4...', '15 prefix') rather than the schema's generic 'any common format'. It also implies the normalization rules applied to the input (strip trunk 0 and mobile 15).
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 gives a specific verb+resource ('Parse and normalize an Argentine phone number') and enumerates accepted input styles with concrete examples. It never names a sibling, but the resource (phone numbers vs. CBU/CUIT/dolar) makes it implicitly distinct from the other ar_* 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?
It clearly states the calling contract ('Send {phone}') and the failure path (unpaid calls return a payment-required result, sign an accepts entry and retry). It does not name alternatives or say when a different tool would be preferable, so it stops short of full when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Daily mid-market exchange rate between two fiat currencies (ISO 4217, e.g. USD, EUR, ARS, BRL, JPY) with optional amount conversion, from blended central-bank reference rates (ECB and others, via Frankfurter). Send {from, to, amount}. Unsupported currency = no charge. Paid tool: 0.002 USDC per call via x402 (USDC on Base, Polygon or Solana, no account or key). An unpaid call returns a payment-required result (isError, structuredContent with x402Version 2 and accepts); sign one of the accepts and retry the same call with the PaymentPayload in params._meta["x402/payment"]. Returns JSON text; the settlement is in result._meta["x402/payment-response"].
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Quote currency ISO 4217 code | |
| from | No | Base currency ISO 4217 code | USD |
| amount | No | Amount in the base currency to convert |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and non-destructive behavior, so the bar is lower — yet the description adds substantial context the annotations cannot convey: cost (0.002 USDC per call via x402 on Base, Polygon, or Solana), the failure mode of an unpaid call (isError, structuredContent with x402Version 2 and accepts), and the exact retry protocol (sign an accepts entry, retry with PaymentPayload in params._meta['x402/payment']). It also says where the settlement appears (result._meta['x402/payment-response']), which is critical for a paid 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 description is front-loaded with purpose and scope, then covers payment mechanics — all of which are necessary for a paid x402 tool. It is a single dense paragraph rather than structured sections, and the x402 retry instructions are verbose, but every sentence carries operational value. Slightly tighter formatting would earn a 5.
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 complexity of a paid x402 tool with no output schema, the description is complete: it explains the payment-required result, the retry handshake, the return format ('Returns JSON text'), and where settlement metadata lives. An agent has everything needed to call it correctly on the first attempt and handle the payment challenge.
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 'to' (quote currency), 'from' (base currency, default USD), and 'amount' (base-currency amount, default 1). The description reinforces this with 'Send {from, to, amount}' and ISO examples (USD, EUR, ARS, BRL, JPY), but adds no syntax or format detail beyond what the schema provides. Baseline 3 applies when the schema does the heavy lifting.
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 gives a specific verb and resource: 'Daily mid-market exchange rate between two fiat currencies (ISO 4217...) with optional amount conversion.' It names the data source (blended central-bank reference rates via Frankfurter) and the exact input shape ({from, to, amount}), so an agent can tell this apart from the Argentina-specific siblings (ar_dolar, ar_cbu, etc.) without opening either 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?
The description implies when to use it (currency conversion between fiat pairs) and states one edge condition — 'Unsupported currency = no charge.' But it never explicitly says when to prefer this over a sibling such as ar_dolar, nor does it state exclusions or prerequisites beyond the payment flow. Usage is inferable but not routed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a complete, responsive single-file HTML landing page for a small business: hero, services, WhatsApp/email call to action, contact section and footer, with inline CSS and SEO meta tags. Requires business_name; optional tagline, description, services, city, whatsapp, email, language (es|en), color and cta_text. Returns the HTML document as text. Free, deterministic template, nothing is stored.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | City or area served | |
| color | No | Brand color as hex, e.g. #0f766e | |
| No | Contact email | ||
| tagline | No | Short headline, e.g. 'Plumbing repairs in 24 hours' | |
| cta_text | No | Main button text | |
| language | No | Page language | es |
| services | No | Up to 8 services. Use 'Title: short description' to add a description. GET: comma-separated | |
| No | WhatsApp number in international format, digits only, e.g. 5491122334455 | ||
| description | No | One or two sentences about the business | |
| business_name | Yes | Business or project name (required) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely new behavioral facts beyond that: output is returned as text, the template is deterministic, it is free, and nothing is stored.
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 what is produced and what it costs. The second sentence's enumeration of parameters is somewhat redundant against a fully documented schema, but it is compact and readable.
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 parameter-rich generator with no output schema, the description does the necessary work: it describes the document's structure, states the return type, and disclaims storage. It leaves minor gaps such as output size or responsiveness caveats, but nothing an agent needs to invoke it correctly is missing.
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 all ten parameters with constraints (maxLength, enum, pattern, defaults). The description's parameter list largely repeats that information rather than adding syntax or interaction detail, so 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 ('Generate a ... single-file HTML landing page') and enumerates the exact sections produced (hero, services, CTA, contact, footer) plus inline CSS and SEO meta tags. An agent can distinguish this from the unrelated sibling get_service_info at a glance.
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 clearly signals the context of use (small business landing page) and states the one hard prerequisite ('Requires business_name'), with everything else marked optional. It does not name when-not-to-use or an alternative, but no plausible competing tool exists in the sibling set.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Describe the done-for-you service: a custom landing page written, designed and published in 24 hours, with a free draft first and payment (USDT/USDC) only if the client likes it. Returns prices, what is included and how to order.
| Name | Required | Description | Default |
|---|---|---|---|
| language | No | Answer language | en |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish that this is a safe, idempotent, read-only, non-open-world call, so the safety profile needs no restating. The description adds genuine business context beyond that: a free draft first, payment only if the client likes the result, 24-hour turnaround, and USDT/USDC as the accepted currencies. It does not cover failure modes or partial-availability behavior, which keeps it short of 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?
It is a single sentence with zero filler and it front-loads the offering before the return contents. The one quibble is that it packs service marketing detail and return-value summary into the same run-on clause rather than separating them, which slightly muddies 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?
For a simple read-only info tool with one optional enum parameter and no output schema, the description covers what the caller gets back (prices, inclusions, how to order) and the commercial terms that govern any follow-up. What it omits is the handoff to generate_landing_page and the ordering mechanics, so an agent knows what the tool says but not precisely what it does next.
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?
There is a single optional 'language' parameter with a fully documented enum (en/es) and 100% schema description coverage, so the schema already carries the meaning with nothing left to explain. The description adds no syntax, format, or default information for it, which is the expected baseline when the schema does the work.
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 ('Describe the done-for-you service') and spells out the concrete offering: a custom landing page written, designed and published in 24 hours with a free draft and conditional USDT/USDC payment. It is clearly distinguishable from the sibling generate_landing_page, which produces a page rather than describing the offering, though it never names that sibling explicitly.
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 by the contract of the tool: an agent calls it to learn prices, inclusions and the ordering flow before committing a client. But there is no explicit when-to-use versus when-not-to-use guidance and no reference to generate_landing_page as the next step, so an agent must infer the sequencing itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List this server's pay-per-call HTTP APIs that agents can buy with USDC via x402 (Base, Polygon or Solana), with URL, price, input schema and an example: Argentina dolar quotes (oficial, blue, MEP, CCL, cripto, tarjeta) and FX exchange rate (0.002), Argentine CUIT/CUIL and CBU/CVU validators and Argentine phone normalizer to E.164 + WhatsApp link (0.01), web page SEO/security audit (0.02) and the landing page generator (0.25). Invalid input is never charged. Free to call; returns JSON text.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive/closed-world, and the description adds genuinely new behavioral facts: calling is free, billing is per-call in USDC on Base/Polygon/Solana, and invalid input is never charged. It also states the response is JSON text with URL, price, input schema and an example per entry — a real disclosure beyond the annotations, though it doesn't cover the payment handshake or rate limits.
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 purpose is front-loaded in the first clause, which is good, but the sentence then becomes a long catalog dump of every API and its price. That pricing detail belongs to the return value rather than to the decision of how to invoke a zero-parameter tool, and the run-on structure makes it harder to scan.
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 carries the burden of describing return content and does so by naming the per-entry fields (URL, price, input schema, example) and the format (JSON text). Combined with the rich annotations, an agent has enough to call it correctly; only the exact envelope shape and any pagination remain unstated.
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 takes zero parameters, so the baseline of 4 applies; there are no parameter semantics for the description to explain. The price figures quoted in the description would only matter to a caller, not as inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource — list this server's pay-per-call HTTP APIs purchasable with USDC via x402 — and enumerates the catalog contents, which makes clear it returns metadata about APIs rather than executing them. Siblings are only referenced indirectly (the landing page generator is listed as a catalog entry, not as a pointer to generate_landing_page), so differentiation is implied rather than explicit.
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 should call this to discover what paid APIs exist and what they cost before invoking one. There is no explicit when-not-to-use guidance and no named alternative (e.g., get_service_info for server-level metadata), so routing between the three siblings is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Quick technical and SEO audit of a public web page: HTTPS and redirect, status, response time, title and meta description, viewport (mobile), h1, canonical, Open Graph, alt text, structured data, compression and security headers. Returns a 0-100 score, grade and prioritized issues. Send {url}. Charged only if the page could be fetched. Paid tool: 0.02 USDC per call via x402 (USDC on Base, Polygon or Solana, no account or key). An unpaid call returns a payment-required result (isError, structuredContent with x402Version 2 and accepts); sign one of the accepts and retry the same call with the PaymentPayload in params._meta["x402/payment"]. Returns JSON text; the settlement is in result._meta["x402/payment-response"].
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Public http(s) URL to audit |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes far beyond the readOnlyHint/openWorldHint/idempotentHint annotations: it discloses the x402 payment requirement and price, the exact failure shape (isError plus structuredContent with x402Version 2 and accepts), the retry mechanism via params._meta["x402/payment"], and where settlement lands (result._meta["x402/payment-response"]). Billing semantics ('charged only if the page could be fetched') are exactly the kind of trait annotations cannot carry.
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 audit scope and result shape, then the payment mechanics — a sensible ordering with no filler sentences. The 15-item checklist is long but each item is a real check the agent may need to reason about; the redundant 'Send {url}' line is the only wasted fragment.
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 still specifies the return payload (0-100 score, grade, prioritized issues, JSON text) and the payment-response envelope. Payment, error, and success paths are all covered, so nothing an agent needs to invoke or recover is missing.
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?
There is a single required parameter with 100% schema description coverage, so the schema already documents it fully. 'Send {url}' adds nothing beyond what the schema states, and the description doesn't clarify edge cases like non-public hosts or redirect targets. Baseline 3 is the correct ceiling here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('technical and SEO audit of a public web page') and then enumerates exactly what is checked (HTTPS/redirect, status, title/meta, viewport, canonical, OG, alt text, structured data, headers). No sibling tool overlaps with page auditing, so no differentiation is needed.
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?
Scope is clear: a public page, one URL, and the billing condition ('charged only if the page could be fetched') tells the agent when cost is incurred. It also tells the agent what to do on the unpaid path (sign an accepts entry and retry), though it never states when *not* to use it — there is no real alternative among the siblings anyway.
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.
ar_cbuar_cuitar_dolarar_feriadosar_inflacionar_phonefx_rateweb_auditlist_paid_apisgenerate_landing_pageget_service_infoArgentina/Brazil data for agents: ARS dollar rates, INDEC CPI, holidays, CUIT/CPF/CNPJ, CEP, PTAX.
Real-time Argentine open data: dollar rates, BCRA, INDEC, AFIP, INFOLEG, SEPA prices. 24+ tools.
Brazil CNPJ, CEP, Selic/IPCA/PTAX, holidays, banks/ISPB for agents. Pay per call in USDC (x402).
Live Argentina data: dolar rates, quiniela and lotteries, holidays, river levels, inflation, news.
Add one secure layer between your agents and this server.