naija-faker-mcp

Generate a fake BVN

generate_bvn

Read-only

Generates a random BVN for test environments, enabling realistic Nigerian bank verification numbers without exposing real customer data.

Instructions

Generates a synthetic BVN for test data only.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "generate_bvn"
  }
}

Input Schema

Name	Required	Description	Default
No arguments

Output Schema

Name	Required	Description	Default
`value`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv2.0.0Sep 16, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "value": {}
+  },
+  "required": [
+    "value"
+  ],
+  "type": "object"
+}

First observedv1.0.1Sep 13, 2026

TDQS

A4.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover read-only and non-destructive behavior. The description adds meaningful behavioral context by stating the output is synthetic and intended for test data only, ruling out any expectation of a real BVN lookup.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single, front-loaded sentence delivers the key facts without redundancy. Every word adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a parameterless generator with an output schema already present, the description is fully sufficient. It tells the agent what is generated and the allowed use, and no invocation details are missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are zero parameters and schema coverage is 100%, so the description does not need to explain any parameter details. The baseline of 4 applies because there is nothing missing for an agent to invoke the tool.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names the exact action ('generates'), the specific artifact ('synthetic BVN'), and the scope ('test data only'). This clearly separates it from sibling generators such as generate_nin or generate_person.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

'For test data only' is an explicit usage context that tells an agent when this generator is appropriate. It does not explicitly enumerate sibling alternatives or when-not-to-use cases, but the boundary is clear enough for a parameterless generator.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.