naija-faker-mcp

Generate a fake person

generate_person

Read-only

Generate a synthetic Nigerian person record with identity and contact details, optionally filtered by gender and language (Hausa, Igbo, Yoruba) for realistic test data.

Instructions

Generates one basic composite person record with identity and contact fields. Use atomic tools when you need only one attribute. Accepts optional language (hausa, igbo, or yoruba) and gender (male or female). Returns one synthetic object.

Input Schema

TableJSON Schema

Name	Required	Description
`seed`	No	Seed for reproducible output; the same seed returns the same record
`gender`	No	The person's gender
`language`	No	The person's language

Output Schema

TableJSON Schema

Name	Required	Description	Default
`email`	Yes
`phone`	Yes
`title`	Yes
`address`	Yes
`fullName`	Yes
`lastName`	Yes
`firstName`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv2.1.0Sep 23, 2026

addedInput schema / properties / seed

Added value: +{
+  "description": "Seed for reproducible output; the same seed returns the same record",
+  "maximum": 9007199254740991,
+  "minimum": -9007199254740991,
+  "type": "integer"
+}

Changed5 schema fields changedv2.0.0Sep 16, 2026

changedInput schema / properties / gender / description

Previous value: -"The gender of the person data. The accepted gender values are male and female"New value: +"The person's gender"

addedInput schema / properties / gender / enum
```
Added value: +[
+  "male",
+  "female"
+]
```

changedInput schema / properties / language / description

Previous value: -"The language of the person data. The available languages are Hausa, Igbo and Yoruba"New value: +"The person's language"

addedInput schema / properties / language / enum

Added value: +[
+  "hausa",
+  "igbo",
+  "yoruba"
+]

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "address": {
+      "type": "string"
+    },
+    "email": {
+      "type": "string"
+    },
+    "firstName": {
+      "type": "string"
+    },
+    "fullName": {
+      "type": "string"
+    },
+    "lastName": {
+      "type": "string"
+    },
+    "phone": {
+      "type": "string"
+    },
+    "title": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "title",
+    "firstName",
+    "lastName",
+    "fullName",
+    "email",
+    "phone",
+    "address"
+  ],
+  "type": "object"
+}

First observedv1.0.1Sep 13, 2026

TDQS

A4/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds that it returns 'one synthetic object', which is somewhat redundant with the output schema. It also mentions 'composite' and 'identity and contact fields', giving a sense of the record's scope, but does not discuss determinism via the optional seed or any edge cases. With annotations carrying the safety burden, the description adds modest contextual value but not rich behavioral detail.

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?

The description is three sentences with no filler. It front-loads the primary purpose, immediately gives a usage exclusion, and then lists parameters and return type. Every sentence earns its place; it is efficient and scannable for an agent.

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

Completeness4/5

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

With an output schema present and full parameter documentation, the description covers the essentials: what it does, when to prefer alternatives, and the nature of the return. It does not mention the difference from generate_people (plural) or generate_consistent_person, but the 'basic composite' label plus the atomic-tool hint provide enough context for an agent to make a reasonable choice. It is largely complete for a read-only synthetic generator.

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

Parameters3/5

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

Schema coverage is 100% — every parameter (seed, gender, language) has a description and gender/language have enums. The description repeats the enums but adds no new meaning beyond the schema. For instance, it does not explain the interplay between seed and reproducibility beyond what the schema says. Baseline 3 is appropriate when the schema fully documents parameters and the description contributes little extra.

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 clearly states the tool generates 'one basic composite person record with identity and contact fields', using a specific verb and resource. It distinguishes itself from atomic tools by explicitly naming the alternative condition ('Use atomic tools when you need only one attribute'), and the word 'basic' hints at the difference from more detailed variants like generate_detailed_person. This makes the tool's purpose unambiguous.

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?

The description provides clear guidance on when NOT to use this tool: when only a single attribute is needed, use atomic tools instead. This is a valuable exclusion. However, it does not address other closely related siblings such as generate_people (plural), generate_consistent_person, or generate_detailed_person, leaving the agent to infer the distinctions. It gives one strong usage rule but lacks a complete routing strategy across all siblings.

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