Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@MadTaco MCP Server validate tax ID 12-3456789"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
npm: @madtaco/mcp
Verification and utility API for AI agents. Validate tax IDs, screen sanctions, verify companies, inspect domains — prepaid USD credits. Failed checks are never charged.
This package is a stdio MCP server that wraps the public MadTaco API at https://api.madtaco.dev/v1. Every response includes credits_charged (0 for free operations). Prefer remote HTTP instead? See HTTP MCP below.
madtaco.dev — product site
Setup guide — Cursor, Claude, Smithery
API docs — OpenAPI reference
Agent skill — integration guide (MCP + REST)
llms.txt — full endpoint catalog
pricing.json — per-operation prices
Health — API status
Server card — tool metadata
Related MCP server: agentmail
npx @madtaco/mcpClaude Desktop config: ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows).
Cursor: .cursor/mcp.json in your project or global MCP settings.
{
"mcpServers": {
"madtaco": {
"command": "npx",
"args": ["-y", "@madtaco/mcp"],
"env": {
"MADTACO_API_KEY": "your_api_key_here"
}
}
}
}Without an API key: validate_tax_id, validate_iban, lookup_instrument, validate_email (syntax), validate_phone (format), create_account, verify_account.
With an API key (tier registered): get_usage, propose_check.
Funded account required (tier 2): paid screening/verification tools and validate_email/validate_phone full modes. Top up via POST /v1/billing/checkout or madtaco.dev billing.
Rate limits: 50 req/day anonymous (per IP), 100 req/day registered (per API key), 500/day included once funded — see llms.txt.
Validate the Chilean RUT
11.111.111-1using MadTaco.
Check whether IBAN
DE89370400440532013000is valid.
Look up ticker
CMGon exchangeUS.
Streamable HTTP MCP on the API subdomain — no npm install required:
{
"mcpServers": {
"madtaco": {
"url": "https://api.madtaco.dev/mcp",
"headers": { "X-Api-Key": "your_api_key_here" }
}
}
}Authenticate with X-Api-Key or Authorization: Bearer. Same 13 tools as this stdio package.
Variable | Required | Default |
| For authenticated and paid tools | — |
| No |
|
Override for staging or local dev:
"env": { "MADTACO_API_BASE": "https://api.madtaco.dev/v1" }All paths are relative to MADTACO_API_BASE (default https://api.madtaco.dev/v1).
Tool | API endpoint | Credits |
|
| 0 |
|
| 0 |
|
| 0 |
|
| 0 (syntax) / 0.005 (full, tier 2) |
|
| 0 (format) / 0.005 (full, tier 2) |
|
| 0.10 |
|
| 0.15 |
|
| 0.05 |
|
| sum of completed checks |
|
| pledge hold only |
|
| 0 |
|
| 0 |
|
| 0 |
Call these directly against the API — see llms.txt:
GET /data/cl/{indicator} — Chilean indicators (UF, UTM, USD, EUR, IPC)
GET /balance — credit balance (get_usage includes balance)
GET /evidence/{id} — signed evidence URLs
GET /health — uptime check
create_account with an email → account_id + pending_verification
Human or agent reads the 6-digit code from email
verify_account → api_key (tier registered)
Fund the account via madtaco.dev billing or POST /v1/billing/checkout
Set MADTACO_API_KEY and run paid checks
Credentials never transit through MCP responses for human dashboard access — use POST /v1/accounts/invite-human when needed.
Stdio transport only — this server calls the public HTTP API; no database or secrets beyond an optional API key.
git clone https://github.com/madtaco-dev/mcp.git
cd mcp
npm install
npm test
npm run build
MADTACO_API_KEY=... npm run devNew tools ship as minor npm releases as the API grows. See llms.txt for the current tool list.
MIT © 🌮 MadTaco · Built for agents, literally.
Create a MadTaco account (agent-native signup). A 6-digit verification code is emailed — no API key yet.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Optional display name. | |
| Yes | Account email (disposable domains rejected). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It adds useful context: a 6-digit verification code is emailed and no API key is given yet. However, it omits other behavioral traits such as side effects (e.g., database writes), authorization requirements, or rate limits. Some gaps remain.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, directly to the point, and front-loads the core action. Every sentence adds value: first sentence states what it does, second explains the unique outcome. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 params, no nested objects, no output schema), the description is nearly complete. It explains the purpose and the verification process. Missing is any mention of the return value (e.g., success message or status) and what happens if the account already exists. Still, it covers the essential context for an agent to use it.
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 covers 100% of parameter descriptions (e.g., 'Optional display name' and 'Account email (disposable domains rejected)'). The tool description adds no additional parameter-level meaning beyond the schema. With full schema coverage, the baseline is 3.
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 action ('Create'), the resource ('MadTaco account'), and the specific process ('agent-native signup'). It distinguishes the tool from sibling verification and lookup tools by noting that a verification code is emailed and no API key is provided yet.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for creating a new account, which is distinct from sibling tools (all verification/lookup). However, it does not explicitly state when not to use it or mention alternatives. The context is clear but lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get today usage totals, per-operation counts, credits spent, and balance. Optional period=7d|30d for daily breakdown.
| Name | Required | Description | Default |
|---|---|---|---|
| period | No | Include daily breakdown for the last 7 or 30 days. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the burden. It describes a read operation (get usage) with no mention of side effects, rate limits, or authentication needs. The description is transparent enough for a simple data retrieval tool but lacks explicit behavioral guarantees.
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: the first states the main purpose and output, the second explains the optional parameter. No wasted words, front-loaded with the key action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only one optional parameter, no output schema, and no annotations, the description adequately covers what the tool does and its primary output. It could mention that the operation is read-only or that it returns today's data by default, but it is still complete enough for an AI agent to use 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% with one parameter. The description restates the parameter's purpose and values ('7d|30d for daily breakdown'), adding context that the parameter is optional. Baseline of 3 is appropriate as the description adds value but doesn't extend beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'get', the resource 'usage totals', and lists the specific data items: per-operation counts, credits spent, and balance. It distinguishes from sibling tools which are all about validation, screening, and account management.
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 explicitly mentions the optional period parameter for daily breakdown, giving context on when to use that feature. It does not explicitly state when not to use the tool or provide alternatives, but given the sibling tools are in different domains, the usage context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Inspect domain age, DNS posture, and lookalike risk. Costs 0.05 credits (tier 2).
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Domain to inspect, e.g. example.com. | |
| idempotency_key | No | Optional Idempotency-Key header. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only mentions cost (0.05 credits, tier 2) but not rate limits, authentication needs, or side effects. The description is insufficient for a tool with no annotations.
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 sentence with no fluff, plus a cost note. Every word adds value, and it is front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should hint at return values (e.g., what age, DNS posture, risk information looks like). It does not, leaving the agent uncertain about what the tool returns. The description is too sparse for a moderately complex inspection 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?
Input schema has 100% description coverage for both parameters. The description adds no additional semantics beyond what the schema already provides, so baseline score of 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 clearly states the tool inspects domain age, DNS posture, and lookalike risk, which is a specific verb+resource combination. It distinguishes from sibling tools like validate_email or screen_sanctions by focusing on domains and risk assessment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives in the sibling list. The cost mention (0.05 credits, tier 2) is a minor hint but not explicit about when-to-use or when-not-to-use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Map a ticker, ISIN, CUSIP, or other identifier to FIGI and instrument metadata via OpenFIGI. Free — no API key required.
| Name | Required | Description | Default |
|---|---|---|---|
| id_type | Yes | OpenFIGI idType, e.g. TICKER, ID_ISIN, ID_CUSIP, ID_BB_GLOBAL. | |
| currency | No | Optional ISO 4217 currency filter. | |
| id_value | Yes | Third-party identifier value to map. | |
| mic_code | No | Optional MIC filter (not with exchange_code). | |
| exchange_code | No | Optional exchange code filter (not with mic_code). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'Free — no API key required' which adds cost/auth context, but does not disclose rate limits, error handling, or response format. Minimal behavioral detail for a lookup 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?
Two sentences, no wasted words, front-loaded with the key action and context. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has 5 parameters, no output schema, and no annotations. Description lacks details on return format, error scenarios, and filtering behavior, making it incomplete for an agent to fully understand the tool's capabilities.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with all parameters described, so baseline is 3. The description does not add parameter-level meaning beyond the schema, e.g., id_type values or filter restrictions.
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 explicitly states it maps identifiers (ticker, ISIN, CUSIP) to FIGI and instrument metadata via OpenFIGI, using specific verbs and resources. It clearly distinguishes from siblings which are validation and screening tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it (for mapping financial identifiers) but does not explicitly state when not to use it or mention alternatives. However, siblings are unrelated, so no confusion arises.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Propose a new check capability MadTaco does not offer yet. Optionally pledge credits (held, not charged).
| Name | Required | Description | Default |
|---|---|---|---|
| capability | Yes | Description of the capability you want. | |
| pledge_credits | No | ||
| expected_monthly_volume | No | ||
| willing_to_pay_per_call | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for behavioral disclosure. It does mention that credits are 'held, not charged,' which indicates a non-destructive action. However, it does not explain what happens after proposal (e.g., if a record is created, if follow-up is needed, or if any side effects occur). This is moderate transparency but could be improved.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences that directly state the purpose and a key behavioral detail. There is no redundancy or filler. Every word earns its place, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, and the description does not explain what the tool returns or what happens after a successful proposal. The 4 parameters are only partially clarified (25% schema coverage). For a proposal tool, details like confirmation, status, or next steps are absent. It is minimally adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25% (only 'capability' has a description). The description adds meaning for 'pledge_credits' by stating 'held, not charged,' but does not explain 'expected_monthly_volume' or 'willing_to_pay_per_call'. Given low coverage, the description should compensate more to clarify all parameters. It fails to do so sufficiently.
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's purpose: proposing a new check capability not yet offered by MadTaco. The verb 'propose' and resource 'check capability' are specific, and the additional option of pledging credits adds clarity. The sibling tools are all existing capabilities (lookups, validations, etc.), so this tool is well-distinguished as a request for new features.
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 'does not offer yet' implies usage when a capability is missing, which is a reasonable context. However, there is no explicit guidance on when not to use this tool (e.g., if the capability already exists) or mention of alternatives (e.g., using an existing check tool from siblings). The description is adequate but lacks exclusionary guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a composite trust screen across sanctions, registry, domain, email, and phone checks. Only completed checks are charged. Optionally long-polls when still running.
| Name | Required | Description | Default |
|---|---|---|---|
| checks | Yes | Checks to run in parallel. | |
| entity | Yes | Entity identifiers — each check uses what it needs. | |
| max_credits | No | Hard spend cap; excess checks are skipped. | |
| wait_seconds | No | Long-poll up to N seconds when status is queued/running. | |
| idempotency_key | No | Optional Idempotency-Key header. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description partially discloses behavior: charging only completed checks and long-polling. However, it omits details on error handling, timeout behavior, and result format, which are important for a composite 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?
Two concise sentences, front-loaded with purpose and scope, followed by key behavioral details. No wasted words, 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?
Despite complexity (5 checks, nested entity object, optional long-poll), the description lacks any mention of output format, error scenarios, or when checks time out. Without an output schema, the agent has limited understanding of what results look like.
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%, but the description adds significant value by explaining that entity fields are used as needed per check, checks run in parallel, max_credits is a hard spend cap, and wait_seconds controls long-poll. This goes beyond the schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it runs a composite trust screen across five specific check types, distinguishing it from individual sibling tools like screen_sanctions or validate_email. The verb and resource are specific and the scope is well-defined.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides cost implication (only completed checks charged) and optional long-polling behavior, but does not explicitly state when to choose this composite tool over individual ones. Context is helpful but could be more directive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Screen a name against OFAC SDN, EU, UK, and UN sanctions lists. Costs 0.10 credits (tier 2).
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Name to screen. | |
| country | No | Optional ISO country hint. | |
| idempotency_key | No | Optional Idempotency-Key header. | |
| match_threshold | No | Similarity threshold, default 0.85. |
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 cost but does not mention behavioral traits like idempotency, side effects, or safety. The read-only nature is implicit but not explicitly stated.
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 concise sentence that includes both purpose and cost. No fluff, every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema is provided, and the description does not explain return values or matching behavior. With 4 parameters and no further details beyond schema, the description is incomplete for a tool of this complexity.
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 does not add extra meaning beyond what the schema already provides for parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Screen a name against OFAC SDN, EU, UK, and UN sanctions lists.' It uses a specific verb and resource, and distinguishes from sibling tools like 'screen' by specifying the exact lists.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'screen' or 'propose_check'. The description mentions cost but does not provide context for usage decisions or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate an email address. mode "syntax" is free; mode "full" costs 0.005 credits (tier 2).
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | syntax (free) or full (paid). | |
| address | Yes | Email address to validate. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses cost implications for full mode and tier level. With no annotations, this added behavioral info is valuable. Could mention rate limits or result format but not required.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no wasted words. Information is front-loaded and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema provided, and description fails to explain what the tool returns (e.g., boolean, object). For a validation tool, this is a significant gap. Would be a 4 if output was described.
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 covers 100% of parameters with descriptions. Description adds the cost difference between modes over the schema's 'free' and 'paid' labels. Adds value beyond 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?
Explicitly states it validates an email address, with two modes. Clearly distinguishes from sibling validation tools like validate_tax_id or validate_iban.
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?
Clear that syntax mode is free and full mode costs credits, implying when to use each. Does not explicitly state when not to use or suggest alternatives, but given sibling diversity, it's sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate an IBAN checksum and parse country and bank code. Free — no API key required.
| Name | Required | Description | Default |
|---|---|---|---|
| iban | Yes | IBAN to validate, e.g. "DE89370400440532013000". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool is free and performs validation and parsing, which is sufficient for a straightforward read-only operation. No contradictions or misleading statements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence specifying the core functionality plus a brief note about cost/API key. No unnecessary words, and the key information 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?
Given the tool's simplicity (one parameter, no output schema), the description covers the essential functionality. However, it does not describe the return value format (e.g., whether it returns a boolean or structured data), leaving minor ambiguity.
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% for the single parameter 'iban'. The description adds an example value ('DE89370400440532013000'), providing concrete guidance beyond the schema's definition.
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 validates an IBAN checksum and parses country and bank code. It distinguishes itself from sibling validation tools by specifying the resource (IBAN) and the specific operations (checksum validation, parsing).
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 includes a note that it is free and requires no API key, which is useful for usage decisions. However, it does not explicitly state when to use this tool versus alternatives like validate_tax_id or validate_email, though the specificity to IBAN makes it clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate a phone number. mode "format" is free; mode "full" costs 0.005 credits (tier 2).
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | format (free) or full (paid). | |
| number | Yes | Phone number, E.164 preferred. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description adds behavioral context: mode 'format' is free, mode 'full' costs 0.005 credits. However, it does not disclose return format, error behavior, or other traits expected for a validation 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?
Two sentences with no waste. The tool's purpose is front-loaded in the first sentence, and the second adds essential cost detail. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite low complexity, the description lacks completeness. No output schema exists, and the description does not explain what the validation result looks like (e.g., boolean, details). Agent cannot infer return behavior or error handling.
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 repeats mode cost information already in the schema's property description, adding minimal extra semantics. No additional explanation of number format is provided beyond 'E.164 preferred' in schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Validate a phone number', specifying the verb and resource. It distinguishes from sibling tools like validate_email or validate_tax_id by focusing on phone numbers. The mention of two modes with cost context adds specificity.
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 (validate phone numbers) but provides no explicit guidance on when not to use or alternatives. No exclusions or comparisons to siblings are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate a tax ID format and checksum. Supports CL RUT, MX RFC, and more. Free — no API key required.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Tax ID to validate, e.g. "11.111.111-1". | |
| country | Yes | ISO 3166-1 alpha-2 country code, e.g. "CL". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes core behavior (format and checksum validation) and notes no cost/API key, but with no annotations, it misses additional details like error handling 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?
Two concise sentences, front-loaded with purpose, no extraneous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple tool with 2 explicit parameters and no output schema; could mention return type.
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 covers parameters fully with examples; description adds context via supported tax ID formats, but no further semantic enhancement beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Validate a tax ID format and checksum' with specific examples like 'CL RUT, MX RFC', distinguishing it from sibling validation 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?
Mentions it's free and no API key needed, but lacks explicit guidance on when to use versus alternatives or when not to use (e.g., unsupported countries).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify the emailed 6-digit code and receive an API key (tier registered).
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | 6-digit verification code from email. | |
| account_id | Yes | account_id from create_account. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry full weight. It states verification and API key receipt, but lacks details about side effects, rate limits, or behavior on invalid codes, leaving some 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?
The description is a single, concise sentence with no redundant information. It is efficiently 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?
Given the tool's simplicity (2 params, no output schema, no annotations), the description adequately covers the core action. However, it could mention return value details or error handling for completeness.
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% for the two parameters. The description adds marginal context (6-digit code, account_id from create_account) but does not significantly enhance understanding beyond the schema definitions.
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's purpose: verifying a 6-digit code to receive an API key. It specifies the resource (emailed code) and outcome (API key with tier), effectively distinguishing it from siblings like create_account or verify_company.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage after account creation by referencing account_id from create_account, but it does not explicitly state when to use this vs. alternatives, nor does it provide any when-not conditions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify a company against an official registry (GB only in v1). Costs 0.15 credits (tier 2).
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Company name. | |
| country | Yes | ISO 3166-1 alpha-2 country code. | |
| idempotency_key | No | Optional Idempotency-Key header. | |
| registration_number | No | Registry number. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses cost and scope, but does not state whether the operation is read-only or what side effects occur. The verb 'verify' implies a lookup, but transparency could be improved.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: first states purpose and limitation, second states cost. No fluff, front-loaded with essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks information about the tool's return value (e.g., boolean or details). Without an output schema, this is a gap. Input parameters are well-documented, but output context 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%, but the description adds a constraint: 'GB only in v1' restricts the country parameter to 'GB' beyond the schema's ISO code format. This adds meaningful semantic context.
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's purpose: 'Verify a company against an official registry' and explicitly limits scope to 'GB only in v1'. This distinguishes it from sibling verification tools for tax IDs, IBANs, emails, etc.
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 specifies the geographic limitation ('GB only in v1'), indicating when to use. It also mentions the cost (0.15 credits, tier 2) for budget decisions. However, it does not explicitly state when not to use or suggest alternatives.
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.1.3create_accountget_usageinspect_domainlookup_instrumentpropose_checkscreenscreen_sanctionsvalidate_emailvalidate_ibanvalidate_phonevalidate_tax_idverify_accountverify_companyScored across 13 tools
Tools have distinct purposes: instrument lookup, various validations, sanctions, company, domain, composite screening, account creation, and usage. The composite 'screen' tool overlaps with individual checks but is described as a batch operation, so it remains distinguishable.
All tools use snake_case with a clear verb_noun pattern (e.g., lookup_instrument, validate_email, create_account). The naming is consistent and predictable across the entire set.
13 tools is well-scoped for a financial/identity verification service. Each tool serves a clear role without being excessive or insufficient.
Core verification and screening operations are covered. Minor gaps exist in account management (update/cancel) and listing supported validation types, but these do not severely impact primary workflows.
EU compliance checks for AI agents: sanctions, company, VAT ID, IBAN, email. Pay per call.
European business verification for AI agents: registry, VAT, sanctions, IBAN. Pay-per-call x402.
Deterministic Mexican/LatAm verification + sanctions & PEP screening for AI agents. Pay via x402.
Pay-per-use APIs for agents: web research, data lookups, and metered endpoints billed to credits.
