afro.tools

io.github.afrotools/afrotoolsVersion 1.0.1

Open-source API specs for African providers (payments, SMS, KYC, delivery) for AI agents.

Status

Responds206 msNov 14, 2026, 14:44 UTCAnswered our handshake without sign-in.

Registry data may be out of date

We could not refresh it, so this page shows the last copy.

Last checked: Nov 14, 2026, 14:44 UTC
Latency: 206 ms
Remotes responding: 1 of 1
Sign-in: No sign-in
Hosting: EU hosting detected (detected, not a legal statement)
Registry data as of: Nov 14, 2026, 21:12 UTC

Data from the official MCP Registry, checked by run.zero. How we check

Connect

Streamable HTTP

https://mcp.afro.tools/mcpResponds206 msNov 14, 2026, 14:44 UTC

No sign-in

Claude Code

claude mcp add --transport http afrotools https://mcp.afro.tools/mcp

Claude Desktop and claude.ai

1
2
3

Settings > Connectors > Add custom connector
Name: afrotools
Remote MCP server URL: https://mcp.afro.tools/mcp

Cursor

{
  "mcpServers": {
    "afrotools": {
      "url": "https://mcp.afro.tools/mcp"
    }
  }
}

VS Code

code --add-mcp '{"name":"afrotools","type":"http","url":"https://mcp.afro.tools/mcp"}'

Built your own server? run.zero hosts MCP servers on European infrastructure.

Host your own MCP server on run.zero

Tools

5 tools

Tools of afro.tools
	Description		Read-only	Idempotent	Open world
`get_spec`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. "account", when present, says who can open the provider's account; list_providers and search_specs add its open questions (caps, conditions) and sources. "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" - varia	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. "account", when present, says who can open the provider's account; list_providers and search_specs add its open questions (caps, conditions) and sources. "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" - varia	No	Yes	Yes	No
`list_providers`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. "account", when present, says who can open the account the API needs, from the provider's own pages: holder is "business_only" (a registered business) or "business_or_individual", for all its countries except those in country_exceptions; documents lists what the pages ask for; open_questions gives caps, conditions and what the pages leave unsaid — tell the user, they can change the answer; sources link to those pages (with checked_at, the reading date). A country with no answer (no holder, not in country_exceptions), or no "account" at all, is not documented: tell the user to check with the provider before signing up, never guess. note is present when the list was trimmed to stay readable: description first, then the accounts' sources and checked_at (each provider's page on afro.tools shows the description, links the sources and gives the date) — never an account's answers or open questions. It says which. Returns: { note?, providers: Array<{ slug, name, category, channels?, all_verified, verified_count, capabilities, country_code, docs_public, docs_url, description?, account? }> }	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. "account", when present, says who can open the account the API needs, from the provider's own pages: holder is "business_only" (a registered business) or "business_or_individual", for all its countries except those in country_exceptions; documents lists what the pages ask for; open_questions gives caps, conditions and what the pages leave unsaid — tell the user, they can change the answer; sources link to those pages (with checked_at, the reading date). A country with no answer (no holder, not in country_exceptions), or no "account" at all, is not documented: tell the user to check with the provider before signing up, never guess. note is present when the list was trimmed to stay readable: description first, then the accounts' sources and checked_at (each provider's page on afro.tools shows the description, links the sources and gives the date) — never an account's answers or open questions. It says which. Returns: { note?, providers: Array<{ slug, name, category, channels?, all_verified, verified_count, capabilities, country_code, docs_public, docs_url, description?, account? }> }	No	Yes	Yes	No
`report_integration`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.	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.	No	Yes	Yes	No
`request_spec`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), or needs a capability in a country where no listed provider offers it (search_specs with country first). This helps maintainers prioritize which specs and providers to add next. Args: - capability (string): Capability name e.g. "create_payment", or what is needed e.g. "ussd" - provider (string?): Provider slug e.g. "wave" — omit when no provider is named - country_code (string?): ISO 3166-1 alpha-2 code e.g. "SN" — required when provider is omitted - follow_up ("none" \| "github_issue", default "none"): "none" records the request only; "github_issue" also returns issue_url, a pre-filled GitHub issue the user can review and submit Returns: { logged: true, count, issue_url? } if the request was recorded — count is the all-time number of times this provider + capability (or, without a provider, capability + country) was requested, including this one (a repeated request counts again). count is absent if it could not be determined: do not guess a number. issue_url only with follow_up "github_issue": give it to the user, who submits it. { logged: false, reason: "spec already exists" }: the spec is in the registry — use the existing spec (get_spec) instead. isError if the request could not be stored: tell the user it was NOT recorded.	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), or needs a capability in a country where no listed provider offers it (search_specs with country first). This helps maintainers prioritize which specs and providers to add next. Args: - capability (string): Capability name e.g. "create_payment", or what is needed e.g. "ussd" - provider (string?): Provider slug e.g. "wave" — omit when no provider is named - country_code (string?): ISO 3166-1 alpha-2 code e.g. "SN" — required when provider is omitted - follow_up ("none" \| "github_issue", default "none"): "none" records the request only; "github_issue" also returns issue_url, a pre-filled GitHub issue the user can review and submit Returns: { logged: true, count, issue_url? } if the request was recorded — count is the all-time number of times this provider + capability (or, without a provider, capability + country) was requested, including this one (a repeated request counts again). count is absent if it could not be determined: do not guess a number. issue_url only with follow_up "github_issue": give it to the user, who submits it. { logged: false, reason: "spec already exists" }: the spec is in the registry — use the existing spec (get_spec) instead. isError if the request could not be stored: tell the user it was NOT recorded.	No	No	No	Yes
`search_specs`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"	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"	No	Yes	Yes	No

Details

Registry status: Active
Published: Oct 31, 2026
Updated: Oct 31, 2026
Website: https://afro.tools/⁠ (opens in a new tab)
Repository: https://github.com/afrotools/afrotools⁠ (opens in a new tab)
Categories (suggested): Communication Security Finance and paymentsSuggested categories are assigned automatically from the registry text and may be wrong. Verified operators can correct them.
GDPR: Not declared

Are you the operator? Claim this listing