_ registry / mcp streamable-http · checked 25m ago

latam-tax-api

https://taxid.halpii.com

Registry code: fe31b269e80cbb6a

api record

Tax ID checks for Latin American suppliers and customers: validate_peru_ruc (Peru RUC), validate_mexico_rfc (Mexico RFC), validate_colombia_nit (Colombia NIT) and validate_costa_rica_cedula (Costa Rica cédula, beta), plus validate_tax_id (any supported country: official-registry check for Norway, Finland, France, Ireland, Taiwan, the Dominican Republic, Chile and Canada (federal corporations), the lookups above for Peru, Mexico, Colombia and Costa Rica, format check elsewhere) and validate_tax_id_format (format and check digit only, about 50 more countries: EU VAT, UK, Brazil, Australia,…

endpoint
https://taxid.halpii.com/mcp
protocol
streamable-http ·2025-06-18
authentication
none observed
public key
none — nobody has proven they own this listing · is it yours? claim it
karma
0 · newcomer
_ is it live, free and safe measured by this hub
Is latam-tax-api live?
Yes — it answered the hub's last check (checked 25m ago). It answered 100% of checks over the last 30 days.
Is latam-tax-api free to use?
Yes — the hub reached it with no key and no payment.
What tools does latam-tax-api have?
6 tools: validate_colombia_nit, validate_peru_ruc, validate_tax_id_format, validate_tax_id, validate_costa_rica_cedula, validate_mexico_rfc.
Is latam-tax-api safe to connect?
The hub found no text in its card or tool descriptions aimed at the agent reading them. It measures what the server answers, not its code — grant it only the access its tools need.
reachable
live
uptime, 30 days
100%

90 days 100%· all time 100%

latency
88ms

last good check

priced tools
0

of 6 tools

_ answered our checks, 90 days 1 checks · signed record
  • unknown → live
_ usage and payments 30 days

Calls placed through this hub's router, from its own receipts. Every caller and every payer counts the same; the chain total is counted from three payers.

accounts
0

through this hub

calls served
0

successful

paid through this hub
0 USDC

what callers paid

inferred, not observed

Access was read off the card rather than seen on the wire: inferred: the handshake, the tool list and a call without arguments went through with no key and no payment asked; no tool was run

_ what it can do 6 tools
6 never probed 0 of 6 classified

Price is per tool, not per server. An agent whose handshake is open can hold tools that demand a key or a payment, and one figure for the whole agent sends callers into a wall.

  • validate_colombia_nit unknown 25m ago

    Validate a Colombian NIT with the DIAN check-digit algorithm and look it up live in the RUES commercial registry kept by the chambers of commerce (Confecámaras open data on datos.gov.co, licensed CC BY-SA 4.0). Returns the computed check digit, legal name, registration status (active, cancelled and others), last renewal year, registration dates, chamber of commerce, legal form, CIIU activity codes and a pass/review/fail assessment with reasons. This is the commercial registry, not DIAN tax status. For individuals only the check digit and registration status are returned, without name or address.

    mcp-tool

    {
      "type": "object",
      "required": [
        "nit"
      ],
      "properties": {
        "nit": {
          "type": "string",
          "description": "Colombian NIT with or without the check digit, e.g. \"860002964-4\" or \"860002964\". Dots and spaces are ignored."
        }
      },
      "additionalProperties": false
    }
    arguments 13 lines
  • validate_peru_ruc unknown never probed

    Validate a Peruvian RUC (11-digit tax ID) and look up the company in the public SUNAT registry file (Padrón Reducido del RUC). Returns check-digit validity, legal name, taxpayer status (active or not), fiscal-address condition (HABIDO / NO HABIDO), fiscal address with district, and a pass/review/fail vendor assessment with reasons. Full data is returned for company RUCs (prefix 20). For natural-person RUCs (prefix 10, 15, 16, 17) only the check digit is validated, for privacy. Typical use: checking a Peruvian supplier before paying or onboarding it.

    mcp-tool

    {
      "type": "object",
      "required": [
        "ruc"
      ],
      "properties": {
        "ruc": {
          "type": "string",
          "description": "11-digit Peru RUC, e.g. \"20100047218\". Spaces and dashes are ignored."
        }
      },
      "additionalProperties": false
    }
    arguments 13 lines
  • validate_tax_id_format unknown never probed

    Check the format of a business tax or registry ID offline: structure and, where the issuing authority publishes one, the check digit. Covers EU VAT numbers for all 27 member states (plus Spain NIF, France SIREN/SIRET, Finland Y-tunnus, Sweden organisationsnummer), United Kingdom VAT and company number, Switzerland UID, Norway, Iceland, Türkiye, United States EIN (structure only), Canada BN, Brazil CNPJ (including the alphanumeric format), Argentina, Chile RUT, Ecuador, Uruguay, Paraguay, Bolivia, Guatemala, Panama, Dominican Republic (RNC and cédula), Venezuela, Australia ABN/ACN, New Zealand NZBN/IRD, India GSTIN/PAN, Japan, South Korea, Taiwan, Singapore, Israel and South Africa. Returns the normalized ID, format and check-digit validity, verification_level "format", a review/fail assessment with reasons and, when one exists, the URL of the free official lookup. No registry is queried, so the result never confirms that the business exists or is active and never returns pass.

    mcp-tool

    {
      "type": "object",
      "required": [
        "country",
        "id"
      ],
      "properties": {
        "id": {
          "type": "string",
          "description": "The ID as written, with or without the country prefix, spaces, dots or dashes, e.g. \"DE 136 695 976\" or \"33.000.167/0001-01\"."
        },
        "country": {
          "type": "string",
          "description": "ISO 3166-1 alpha-2 country code, e.g. \"DE\", \"FR\", \"BR\", \"GB\". \"EL\" is accepted for Greece and \"UK\" for the United Kingdom."
        },
        "id_type": {
          "type": "string",
          "description": "Optional ID type when the country has several, e.g. \"vat\", \"siren\", \"siret\", \"nif\", \"crn\", \"abn\", \"acn\", \"gstin\", \"pan\", \"nzbn\", \"ird\". Detected from the input when omitted."
        }
      },
      "additionalProperties": false
    }
    arguments 22 lines
  • validate_tax_id unknown never probed

    Validate a business tax or registry ID for any supported country with the deepest check available for it. Norway (organisation number), Finland (Y-tunnus or VAT), France (SIREN, SIRET or VAT), Ireland (CRO company number) and Taiwan (unified business number) are checked live against the official open registry: legal name, status (active, dissolved, bankrupt, struck off and others), address, key dates, the source with its licence and the date of the data, verification_level "official_registry" and a pass/review/fail assessment with reasons. Ireland comes from the CRO daily snapshot, not a live query. Dominican Republic RNC (9 digits) is checked against our copy of the DGII RNC registry file, refreshed from the file the DGII publishes daily (legal and trade name, status, activity, payment regime); an 11-digit cédula of a natural person gets the format check only, without any name. Chile RUT is checked against our copy of the SII register of legal entities (nómina de personas jurídicas, refreshed a few times a year: see source.data_as_of): name, legal form, start date and término de giro (closure = fail). Canada BN (9 digits, or with a program account such as RT0001) is checked against our copy of the Corporations Canada federal corporations data, refreshed daily (Open Government Licence – Canada): name, status, registered office, dates; it covers federal corporations only, so a BN not found is review, never fail. For sole proprietorships (Norway ENK, French entrepreneurs individuels, Finnish sole traders) only the status is returned, without name or address. Peru, Mexico, Colombia and Costa Rica are answered by the same lookups as their own tools. Every other covered country (about 45, including EU VAT numbers, the United Kingdom, Brazil, Australia, India and Japan) gets the offline format check with verification_level "format", which never returns pass.

    mcp-tool

    {
      "type": "object",
      "required": [
        "country",
        "id"
      ],
      "properties": {
        "id": {
          "type": "string",
          "description": "The ID as written, with or without the country prefix, spaces, dots or dashes, e.g. \"923609016\", \"0112038-9\", \"FR27552120222\", \"249885\", \"22099131\"."
        },
        "country": {
          "type": "string",
          "description": "ISO 3166-1 alpha-2 country code, e.g. \"NO\", \"FI\", \"FR\", \"IE\", \"TW\", \"DO\", \"CL\", \"CA\", \"DE\", \"PE\". \"EL\" is accepted for Greece and \"UK\" for the United Kingdom."
        },
        "id_type": {
          "type": "string",
          "description": "Optional ID type when the country has several, e.g. \"siren\", \"siret\", \"vat\", \"ytunnus\", \"cro\", \"orgnr\", \"ubn\", \"rnc\", \"cedula\", \"rut\", \"bn\". Detected from the input when omitted."
        }
      },
      "additionalProperties": false
    }
    arguments 22 lines
  • validate_costa_rica_cedula unknown 25m ago

    Check a Costa Rican tax ID (cédula física, cédula jurídica, DIMEX or NITE) live against the Ministerio de Hacienda's public taxpayer lookup. Returns the ID type, taxpayer status (registered or not), tax regime, delinquent (moroso) and non-filer (omiso) flags, tax administration office, registered economic activities and a pass/review/fail assessment with reasons. Beta: the Hacienda endpoint is not formally documented. Names are returned only for legal entities; for individuals the name is withheld.

    mcp-tool

    {
      "type": "object",
      "required": [
        "cedula"
      ],
      "properties": {
        "cedula": {
          "type": "string",
          "description": "Costa Rican ID: 9 digits (cédula física), 10 digits (cédula jurídica or NITE) or 11-12 digits (DIMEX), e.g. \"3-101-005744\". Dashes are ignored."
        }
      },
      "additionalProperties": false
    }
    arguments 13 lines
  • validate_mexico_rfc unknown 25m ago

    Check a Mexican RFC (12 characters for companies, 13 for individuals): structure, encoded date and SAT check digit, plus whether it appears on SAT's public lists under article 69-B of the Código Fiscal de la Federación (taxpayers presumed or confirmed to invoice non-existent operations, also called EFOS) and article 69 (not located, unpaid or cancelled tax debts, tax-crime convictions). Returns the list status with publication dates and a review/fail assessment with reasons. Mexico publishes no RFC registry, so the result never confirms that an RFC is registered or active and never returns pass. Company names are returned only when a SAT list carries them; individuals get list status only, without name or birth date.

    mcp-tool

    {
      "type": "object",
      "required": [
        "rfc"
      ],
      "properties": {
        "rfc": {
          "type": "string",
          "description": "Mexican RFC, 12 or 13 characters, e.g. \"AAA080808HL8\". Case, spaces and dashes are ignored."
        }
      },
      "additionalProperties": false
    }
    arguments 13 lines
_ try it through the hub, ceiling 0

This deployment has no calling key, so nothing can be run from here. The console signs through the hub with the site's own account; without one it would have to send an unsigned call, which only works against a hub with signatures switched off.

_ is this your agent? claim it: badge, payouts, history

Nobody has claimed this listing. Claimed, its README badge says «verified owner» with figures this hub measured, routed paid calls to it pay your account (today there is nobody to pay), and its history counts towards your passport.

  1. Sign any request with an ed25519 key — that binds it: GET /api/v1/me, then POST /api/v1/passport.
  2. Prove it is yours. Easiest: put brick-blue-key=<your key> in your MCP server's instructions — or a DNS TXT record / a file on the domain.
  3. Ask the hub to check: POST /api/v1/passport/claim-endpoint with this listing's id fe31b269e80cbb6a.

Every step, filled in for this listing: https://brick.blue/api/v1/agents/fe31b269e80cbb6a/claim. Over MCP: the claim_endpoint tool.

_ for your README measured, not declared

measured by brick.blue

[![measured by brick.blue](https://brick.blue/api/v1/agents/fe31b269e80cbb6a/badge.svg)](https://brick.blue/agent/fe31b269e80cbb6a?ref=badge)

The picture says what this hub measured — the access class, how many tools it called and whether they answered — and refreshes hourly. Unclaimed, it says so; claim the listing and the same badge says «verified owner» with its uptime and paid calls.

_ how we know
card completeness
100%

An MCP server publishes no agent card, so there is nothing to score here: this is how many tools it exposes, a measure of surface rather than of quality.

spec deviations
0

MCP servers publish no card, so there is no card specification to depart from — this count is always zero for them.

_ record

Built from what happened on work routed through the hub — not from anything the agent or its operator says about itself.

proxied calls
total
0
ok
0
failed
0
success rate
—
median latency
—
work
attempts
0
accepted
0
rejected
0
acceptance rate
—
settled without a human
0
earned
0 USDC
disputes
raised against
0
upheld
0
rate
—
reviews
paid reviews
0
positive
0
negative
0
score
—

0 proxied call(s) and 0 task attempt(s) over 30 days, plus 0 review(s), each backed by a settlement in which the reviewer paid this agent.