afro.tools

Lists every provider in the registry with what it offers. Every listed provider is AI Ready: its specs give you a structured description to integrate it from (endpoints, fields, errors, gotchas taken from the provider's docs). verified_count says how many of its capabilities were also tested against the provider's API; all_verified is true when all of them were. When you show this list, present what each provider offers and give the tested capabilities per provider (e.g. "3/4 tested"), not a headline such as "only one provider is fully verified": a capability not tested yet is still documented and usable, it may contain errors. Before integrating one, check its "status" with get_spec and tell the user if it was not tested. Returns: { providers: Array<{ slug, name, category, channels?, all_verified, verified_count, capabilities, country_code, docs_public, docs_url }> }

{
  "type": "object",
  "properties": {},
  "$schema": "http://json-schema.org/draft-07/schema#"
}

Searches specs by words and filters by category, channel, provider, country, currency, status or capability type. Returns the matching providers, each with its countries, currencies, sandbox flag, docs URL and the matching capabilities (name, type, status, example_prompt) — no endpoints, schemas, gotchas or canonical_example source. Use get_spec with the exact capability name to retrieve the full payload. A capability with "variants" has several request/response shapes (e.g. one per payment method or corridor): pass the ones you need to get_spec "variant" to receive only those. Each result includes a "status" field: - "verified": tested against the provider's API, in "sandbox" or "production" (verified_in / verification.environment) - "deprecated": the provider is retiring it — get_spec says what replaces it - anything else (e.g. "ready", "unverified"): written from the provider's documentation, NOT tested against the live API — may contain errors Always check the status field. If status is not "verified", inform the user that the spec is experimental and may contain errors. Args: - query (string?): Words, e.g. "wave", "mobile money senegal", "send sms", "kyc", "XOF". Every word must match somewhere: provider name or slug, capability, description, example_prompt, countries (code or English/French name), currencies, channels (a few synonyms: momo, otp, kyc, payout…). Providers the query names come first. - category (string?): Filter by category, e.g. "payment", "communications" (SMS, WhatsApp, USSD, voice and email providers — "sms" is accepted as a legacy alias), "identity" (KYC, document verification, AML), "logistics" (delivery and courier providers). The registry adds categories over time: list_providers shows every category that exists - channel ("sms"|"whatsapp"|"ussd"|"voice"|"email"?): Only providers that offer this channel - provider (string?): Provider slug e.g. "paycard" - country_code (string?): ISO 3166-1 alpha-2 e.g. "GN" - currency (string?): ISO 4217 e.g. "XOF" - status ("verified"|"ready"|"unverified"?): e.g. "verified" for specs tested against the provider's API - capability_type ("synchronous"|"asynchronous"|"webhook"|"sdk"?): Filter by capability type Returns: { providers: ProviderMatch[], note?: string, hint?: string, unverified_count: number, warning?: string } note is present when example_prompt was left out to keep a wide result readable. hint is present when nothing matched: widen the search before telling the user a provider is unavailable. unverified_count counts matching capabilities whose status is not "verified"; warning is present only when it is > 0.

{
  "type": "object",
  "properties": {
    "query": {
      "description": "Words, e.g. \"mobile money senegal\" — every word must match",
      "type": "string",
      "maxLength": 200
    },
    "category": {
      "type": "string"
    },
    "channel": {
      "type": "string",
      "enum": [
        "sms",
        "whatsapp",
        "ussd",
        "voice",
        "email"
      ]
    },
    "provider": {
      "description": "Provider slug e.g. \"paycard\"",
      "type": "string"
    },
    "country_code": {
      "description": "ISO 3166-1 alpha-2 e.g. \"GN\"",
      "type": "string"
    },
    "currency": {
      "description": "ISO 4217 e.g. \"XOF\"",
      "type": "string"
    },
    "status": {
      "type": "string",
      "enum": [
        "verified",
        "ready",
        "unverified"
      ]
    },
    "capability_type": {
      "type": "string",
      "enum": [
        "synchronous",
        "asynchronous",
        "webhook",
        "sdk"
      ]
    }
  },
  "$schema": "http://json-schema.org/draft-07/schema#"
}

Returns the full spec payload for a provider + capability, including canonical_example.ts source code. Use this to get the complete integration guide — auth pattern, endpoint, schemas, gotchas, and a TypeScript example — before writing API calls. The response includes a "status" field: - "verified": tested against the provider's API, in "sandbox" or "production" (verified_in / verification.environment) - "deprecated": the provider is retiring it — "deprecation" gives the reason, replaced_by (the capability to use instead) and removed_after - anything else (e.g. "ready", "unverified"): written from the provider's documentation, NOT tested against the live API "verification" says how and when it was tested; sandbox proves the request and response shapes, not production behaviour. "open_questions", when present, lists what the provider's docs do not answer: tell the user before relying on the spec. "environments", when present, gives each documented environment's base URL; a missing one is undocumented — ask the user, never guess. "auth.credentials" / "signing" / "token_exchange" / "apply" and "webhook.signature", when present, describe the auth and webhook signature steps exactly: follow them. "parameters", when present, lists the path, query and header parameters; "input_schema" is the request body only. A path parameter fills the {name} placeholder of endpoint.url. "success_condition", when present, names the response field (dotted path) that says the call succeeded: a 2xx response with another value is a failure. If status is not "verified", always warn the user before generating integration code: "This spec has not been tested against the live API yet and may contain errors." Args: - provider (string): Provider slug e.g. "paycard" - capability (string): Capability name e.g. "create_payment" - variant (string[]?): Discriminator values to keep, e.g. ["mobile_money_ghs"] or ["bank", "NGN"]. In every union (oneOf) of input_schema and response_schema, only the branches pinned to one of these values are kept; a union none of them matches is left whole. Without it, all branches are returned. The response lists every value under "variants" (discriminator property → values). A large spec also carries "_mcp_size_note": if your client cut the result, call again with the variant you need. Returns: Full Spec object with canonical_example string (plus _mcp_warning when status is not "verified"). If not found: isError, with { error, available_capabilities } when the provider exists — capability names are each provider's own, pick one from that list — and did_you_mean (closest provider slugs or capability names) when one is close. A capability removed from the registry after a provider deprecation answers isError with removed_in, reason and alternatives. Use search_specs or list_providers first to discover available providers and capabilities.

{
  "type": "object",
  "properties": {
    "provider": {
      "type": "string",
      "maxLength": 64,
      "description": "Provider slug e.g. \"paycard\""
    },
    "capability": {
      "type": "string",
      "maxLength": 64,
      "description": "Capability name e.g. \"create_payment\""
    },
    "variant": {
      "description": "Discriminator values to keep, e.g. [\"mobile_money_ghs\"] — see \"variants\" in search_specs",
      "type": "array",
      "items": {
        "type": "string"
      }
    }
  },
  "required": [
    "provider",
    "capability"
  ],
  "$schema": "http://json-schema.org/draft-07/schema#"
}

Logs a request for a spec that doesn't exist yet and notifies maintainers. Call this when a user asks for a provider or capability that has no spec in the registry (check list_providers first). This helps maintainers prioritize which specs to write next. Args: - provider (string): Provider slug e.g. "wave" - capability (string): Capability name e.g. "create_payment" Returns: { logged: true, count } if the request was recorded — count is the all-time number of requests for this exact provider+capability, including this one, so you can tell the user e.g. "you're the Nth person to ask for this". count is absent if it could not be reliably determined — in that case do NOT guess a number to the user, just confirm the request was logged. { logged: false, reason } if the spec already exists. isError if the request could not be stored: tell the user it was NOT recorded.

{
  "type": "object",
  "properties": {
    "provider": {
      "type": "string",
      "pattern": "^[\\w .-]{1,64}$",
      "description": "Provider slug e.g. \"wave\""
    },
    "capability": {
      "type": "string",
      "pattern": "^[\\w .-]{1,64}$",
      "description": "Capability name e.g. \"create_payment\""
    }
  },
  "required": [
    "provider",
    "capability"
  ],
  "$schema": "http://json-schema.org/draft-07/schema#"
}

Builds a pre-filled GitHub link to report how an integration went against a spec — it worked, or the spec is wrong. Call it when the user confirms an integration works against the real API (sandbox or production), or when you find the spec does not match the API. Reports are how specs get verified and fixed. Nothing is posted: the user reviews the text and submits it on GitHub. One report per provider, covering every capability of the flow (e.g. payment init, status, webhook): each one is verified on its own. Args: - provider (string): Provider slug e.g. "paycard" - capabilities (array): Every capability the integration used, each with its own result e.g. [{ "capability": "create_payment", "result": "worked" }, { "capability": "webhook", "result": "wrong: status is SUCCESSFUL, spec says succeeded" }] - summary (string): One line about the flow, e.g. "checkout flow works in sandbox" - details (string): What was called, what came back, what differed from the spec. NEVER include API keys, tokens, phone numbers or personal data. - tested_on (string?): Date of the test, YYYY-MM-DD Returns: { url, next_step } — give the url to the user and follow next_step. If a spec does not exist: isError, with { error, available_capabilities } when the provider exists.

{
  "type": "object",
  "properties": {
    "provider": {
      "type": "string",
      "maxLength": 64,
      "description": "Provider slug e.g. \"paycard\""
    },
    "capabilities": {
      "minItems": 1,
      "maxItems": 20,
      "type": "array",
      "items": {
        "type": "object",
        "properties": {
          "capability": {
            "type": "string",
            "maxLength": 64,
            "description": "Capability name e.g. \"create_payment\""
          },
          "result": {
            "type": "string",
            "minLength": 1,
            "maxLength": 200,
            "description": "\"worked\", or what differed from the spec"
          }
        },
        "required": [
          "capability",
          "result"
        ]
      },
      "description": "Every capability the integration used, each with its own result"
    },
    "summary": {
      "type": "string",
      "minLength": 1,
      "maxLength": 120,
      "description": "One line"
    },
    "details": {
      "type": "string",
      "minLength": 1,
      "maxLength": 20000,
      "description": "No secrets or personal data"
    },
    "tested_on": {
      "description": "Date of the test, YYYY-MM-DD",
      "type": "string",
      "pattern": "^\\d{4}-\\d{2}-\\d{2}$"
    }
  },
  "required": [
    "provider",
    "capabilities",
    "summary",
    "details"
  ],
  "$schema": "http://json-schema.org/draft-07/schema#"
}