# afro.tools (remote · mcp.afro.tools)

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

- Trust score: 70/100 (medium)
- Registry status: active
- Liveness: live
- Owner verified: no
- Last scored: 2026-11-05

## Components

- remote · `mcp.afro.tools`: 70/100 (this document), [markdown](https://verifymcp.io/servers/afrotools-afrotools/mcp.md), [page](https://verifymcp.io/servers/afrotools-afrotools/mcp)

## Channel facts

- Endpoint: `https://mcp.afro.tools/mcp`
- Transports: `streamable-http`
- Auth: `none`
- Version: `1.0.1`

## Trust breakdown

How this component scores in each security and reliability category. Every signal is checked automatically against the live server, and we only credit what we can confirm. Scores are 0–100 per category. Scoring method: https://verifymcp.io/docs/scoring (what has changed: https://verifymcp.io/docs/scoring/changelog)

Scored 2026-11-05.

- **Endpoint Security**: 74/100
  - The endpoint's TLS certificate is valid, in date, and uses a strong key.
  - No authorisation is required to call this server. Every tool declares its destructiveHint and none is destructive, so open access doesn't expose one.
  - HTTPS is enforced; there's no plaintext access path.
  - HSTS check failed: the Strict-Transport-Security header is absent.
  - DNSSEC check failed: this domain isn't protected by DNSSEC.
- **Transport & Reachability**: 100/100
  - Verified streamable-http transport via a live MCP handshake.
- **Schema Quality & AI Usability**: 57/100
  - AI-judged instruction clarity (excellent).
  - Context-footprint check failed: tool/resource definitions use about 2919 tokens (~583/item across 5 items; 5 tools + 0 resources), over budget; trim descriptions and params.
  - Usage-examples check failed: none of the tools include examples.
- **Stability & Change Management**: 17/100
  - Stability observed for 5 of 30 days with no destabilising changes; credit accrues until the full window elapses.
- **Tool Coverage**: 93/100
  - 100% of tools have a non-trivial description (not blank, and not just the tool's name).
  - 80% of tool parameters carry a description.
- **Tool Safety**: 100/100
  - No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.
  - We read all 5 captured tool definition(s), and no name or description among them implies an irreversible operation.
  - An AI judge read all 6 captured unit(s) of tool text and found none that tries to manipulate the model reading it.
- **Capabilities**: 100/100
  - Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.

## Install

### How do I install the afro.tools MCP server?

afro.tools is a hosted endpoint at https://mcp.afro.tools/mcp, so there is nothing to install locally. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.

### Claude

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

### Cursor

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

### VS Code

```json
{
  "servers": {
    "afrotools-afrotools": {
      "type": "http",
      "url": "https://mcp.afro.tools/mcp"
    }
  }
}
```

### Codex

```toml
[mcp_servers.afrotools-afrotools]
url = "https://mcp.afro.tools/mcp"
```

### opencode

```json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "afrotools-afrotools": {
      "type": "remote",
      "url": "https://mcp.afro.tools/mcp",
      "enabled": true
    }
  }
}
```

### OpenClaw

```bash
openclaw mcp add afrotools-afrotools --url 'https://mcp.afro.tools/mcp' --transport streamable-http
```

### Hermes

```yaml
mcp_servers:
  afrotools-afrotools:
    url: "https://mcp.afro.tools/mcp"
```

### Netclaw

```json
{
  "McpServers": {
    "afrotools-afrotools": {
      "Transport": "http",
      "Url": "https://mcp.afro.tools/mcp"
    }
  }
}
```

### Vellum

```bash
assistant mcp add afrotools-afrotools -t streamable-http -u 'https://mcp.afro.tools/mcp'
```

### Other

```json
{
  "mcpServers": {
    "afrotools-afrotools": {
      "type": "http",
      "url": "https://mcp.afro.tools/mcp"
    }
  }
}
```

The mcpServers block is a cross-client convention. Remote transports vary, so check your client's docs.

## Changelog

Every change recorded for this component, newest first. Days that predate change tracking, or that we cannot explain, say so: "we were watching and nothing happened" and "we were not watching" are different claims.

### 2026-11-05 (score 70, +1)

- [security] Tool “list_providers” rewrote its description, which is the text the model reads
- [security] Tool “search_specs” rewrote its description, which is the text the model reads

### 2026-11-04 (score 69, 0)

- [security] Tool “get_spec” rewrote its description, which is the text the model reads
- [security] Tool “list_providers” rewrote its description, which is the text the model reads
- [security] Tool “request_spec” rewrote its description, which is the text the model reads
- [security] Tool “search_specs” rewrote its description, which is the text the model reads
- [functional regression] Schema quality: 481 → 561
- [cosmetic] “request_spec” added an optional parameter “country_code”
- [cosmetic] “request_spec” added an optional parameter “follow_up”
- [cosmetic] “request_spec” reworded the description of “capability”
- [cosmetic] “request_spec” made “provider” optional

### 2026-11-03 (score 69, 0)

- [security] Tool “list_providers” rewrote its description, which is the text the model reads

### 2026-11-02 (score 69, +1)

No change was recorded against any check on this day. Stability & Change Management went from 3 to 7. That category is still filling its 30-day observation window: 1 days of observed history at the previous scan, 2 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-11-01 (score 68, 0)

- [functional improvement] Stability: unverified → 0.03

### 2026-10-31 (score 68)

First indexed and scored.

## MCP tools (5)

### `list_providers` (~398 tokens)

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? }> }

### `search_specs` (~811 tokens)

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"…

Input parameters:

- `capability_type` (string)
- `category` (string)
- `channel` (string)
- `country_code` (string): ISO 3166-1 alpha-2 e.g. "GN"
- `currency` (string): ISO 4217 e.g. "XOF"
- `provider` (string): Provider slug e.g. "paycard"
- `query` (string): Words, e.g. "mobile money senegal" — every word must match
- `status` (string)

### `get_spec` (~741 tokens)

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"
  \- vari…

Input parameters:

- `capability` (string, required): Capability name e.g. "create_payment"
- `provider` (string, required): Provider slug e.g. "paycard"
- `variant` (array): Discriminator values to keep, e.g. ["mobile_money_ghs"] — see "variants" in search_specs

### `request_spec` (~447 tokens)

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.

Input parameters:

- `capability` (string, required): Capability name e.g. "create_payment", or what is needed e.g. "ussd"
- `country_code` (string): ISO 3166-1 alpha-2 country code e.g. "SN" — required without provider
- `follow_up` (string): "github_issue" also returns issue_url, a pre-filled GitHub issue the user can submit
- `provider` (string): Provider slug e.g. "wave"

### `report_integration` (~385 tokens)

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.

Input parameters:

- `capabilities` (array, required): Every capability the integration used, each with its own result
- `details` (string, required): No secrets or personal data
- `provider` (string, required): Provider slug e.g. "paycard"
- `summary` (string, required): One line
- `tested_on` (string): Date of the test, YYYY-MM-DD

## Diagnostics

Captured diagnostic sections: TLS, DNSSEC, Authorisation, Transports. The full working is on the page: https://verifymcp.io/servers/afrotools-afrotools/mcp#diagnostics

## Score history

- 2026-11-05: 70
- 2026-11-04: 69
- 2026-11-03: 69
- 2026-11-02: 69
- 2026-11-01: 68
- 2026-10-31: 68

## Common questions

### What is the afro.tools MCP server?

afro.tools is an MCP server listed in the public MCP registry as io.github.afrotools/afrotools. Open-source API specs for African providers (payments, SMS, KYC, delivery) for AI agents. This page covers its hosted endpoint (https://mcp.afro.tools/mcp).

### Is the afro.tools MCP server safe to use?

afro.tools scores 70 out of 100 on VerifyMCP. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.

### What tools does the afro.tools MCP server expose?

afro.tools exposes 5 tools: list_providers, search_specs, get_spec, request_spec, report_integration. Their descriptions and schemas cost roughly 2,782 tokens of context every time the server is loaded.

### Does the afro.tools MCP server require authentication?

No. We connected to afro.tools without credentials and it answered, so anything it exposes is reachable by anyone who knows the address.

### Is the afro.tools MCP server still maintained?

afro.tools is still listed as active in the MCP registry. We last reached this channel on 5 November 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.

## Links

- Remote endpoint: https://mcp.afro.tools/mcp
- Repository: https://github.com/afrotools/afrotools
- Website: https://afro.tools/
- Changelog RSS feed: https://verifymcp.io/servers/afrotools-afrotools/mcp.xml
- Changelog JSON feed: https://verifymcp.io/servers/afrotools-afrotools/mcp.json
- HTML version of this page: https://verifymcp.io/servers/afrotools-afrotools/mcp