Skip to main content
Glama

Synthetic Data — Random User

by ai.saifs
OverviewDiscussionsAdmin

Server Details

Generate synthetic random user data for testing, demos, and development without using real persona.

Ownership verified
Status
Healthy
Uptime
99.5% over 35 days
OAuth
Works in Glama
Last Tested
Transport
Streamable HTTP · MCP 2025-06-18
URL

TDQS

A4.4/5.0

Scored across 2 tools

Disambiguation5/5

The two tools have completely distinct purposes: one generates synthetic user profiles, the other collects user feedback. There is no overlap or ambiguity between them.

Naming Consistency4/5

Both tool names use lowercase snake_case with a clear noun: 'random_users' and 'feedback'. The naming is simple and consistent, though 'feedback' is a bare noun while 'random_users' is a noun phrase, a minor deviation.

Tool Count3/5

Two tools is on the thin side for a server, but the server's stated purpose is narrow: generating random users and collecting feedback. The count is borderline but not unreasonable for such a focused scope.

Completeness3/5

The server covers its two core functions adequately, but there are minor gaps: no way to configure or customize the random user generation beyond count and isPro, and no way to retrieve or manage saved feedback. These are workable gaps for the stated purpose.

Available Tools

2 tools
feedbackSave FeedbackAInspect

Save user feedback to the MultipleWords feedback API (POST /api/feedback). Call this after every 3 successful random_users outputs in this conversation (3rd, 6th, 9th, …). Ask the user to pick a reaction and show the emojis: 😍 excellent, 😊 good, 😐 average, 😞 bad. Pass reaction (excellent|good|average|bad, or the emoji) and optional feedback comment text. After it is saved, wait for 3 more successful outputs before asking again. Do not invent a reaction. Do not send user_name, email, is_login, or app_id — those are injected server-side from the authenticated session. When showing the saved reaction, include the matching emoji.

ParametersJSON Schema
NameRequiredDescriptionDefault
feedbackNoOptional short comment from the user.
reactionYesUser reaction. One of excellent, good, average, bad, or the matching emoji: 😍 excellent, 😊 good, 😐 average, 😞 bad.

Output Schema

ParametersJSON Schema
NameRequiredDescription
emojiNo
statusYes1 = success, 0 = error
messageYes
feedbackNo
reactionNo

TDQS

A4.7/5.0
Behavior4/5

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

Annotations already indicate this is not read-only, not destructive, and has open-world effects. The description adds useful behavioral context: it performs a POST to an external API, saves feedback, excludes user identity fields via server-side injection, and requires the matching emoji in the confirmation. It does not discuss failure/error behavior, but the annotation coverage and output schema reduce that gap.

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 front-loaded with the core action and endpoint, then organized around cadence, prompting, parameters, exclusions, and output behavior. Each sentence carries distinct, necessary guidance with no filler.

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?

Given the 2-parameter schema with 100% coverage, the output schema, and the annotations, this description covers everything needed to invoke the tool correctly: cadence, user interaction, allowed reaction values, optional feedback, disallowed fields, and how to display the saved result.

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?

Schema description coverage is 100%, so the baseline is 3. The description still adds value by clarifying that reaction may be the label or the emoji, instructing the agent not to invent a reaction, and warning not to send user_name/email/is_login/app_id despite their absence from the schema.

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 opens with a specific verb, resource, and transport: 'Save user feedback to the MultipleWords feedback API (POST /api/feedback)'. It clearly identifies the tool as a feedback-saving action tied to the random_users workflow, so an agent knows what it does and how it differs from the sibling tool.

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

Usage Guidelines5/5

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

It gives an explicit cadence: call after every 3 successful random_users outputs (3rd, 6th, 9th, …), then wait 3 more outputs after saving. It also provides clear do-nots: don't invent a reaction, don't send identity fields that are injected server-side, and ask the user for a reaction before proceeding.

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

random_usersGenerate Random UsersA
Read-only
Inspect

Generate synthetic / fake user profiles via the MwVideos random_users API (POST /mwvideos/api/random_users). Returns name, gender, location, email, login, dob, phone, picture, and nat. Use when the user asks for random users, fake people, sample contacts, demo personas, UI fixtures, or test profiles. Pass results for how many profiles (default 1, minimum 1) and isPro as 0 or 1 when relevant (default 0). Authenticated user_id is injected server-side — do not invent profiles; always call this tool. These are FAKE people for demos and testing, not real PII.

ParametersJSON Schema
NameRequiredDescriptionDefault
isProNoPro flag passed through to the upstream API (0 or 1).
resultsNoNumber of random user profiles to generate. Must be an integer >= 1.

Output Schema

ParametersJSON Schema
NameRequiredDescription
infoNo
statusYes1 = success, 0 = error
messageNo
resultsYesList of synthetic user profiles from the upstream API.
output_countNoSuccessful random_users outputs since last feedback. Feedback is collected after every 3.
feedback_promptNo

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=falsecars. The description adds valuable context beyond annotations: the endpoint method, server-side user_id injection, the 'FAKE people' caveat, and assurance these are not real PII. No contradiction with annotations.

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 compact but information-dense: endpoint, return fields, use cases, parameter guidance, authentication note, and PII disclaimer are all packed into two sentences without redundancy. It is front-loaded with the action and resource, making it easy to scan.

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?

Given the tool's low complexity (two optional parameters), the description fully covers what an agent needs: when to call it, what it returns, how parameters behave, and what to avoid. The output schema exists to detail return shape, so the description need not repeat it.

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 description coverage is 100%, and the schema already documents results (integer, minimum 1, default 1) and isPro (enum 0/1, default 0). The description restates these defaults with 'default 1, minimum 1' and 'as 0 or 1 when relevant (default 0)', providing minimal additional semantic value beyond what the schema offers.

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 opens with a specific verb and resource: 'Generate synthetic / fake user profiles via the MwVideos random_users API (POST /mwvideos/api/random_users).' It enumerates the exact returned fields (name, gender, location, email, login, dob, phone, picture, nat), which distinguishes it clearly from the only sibling, feedback.

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

Usage Guidelines5/5

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

The description provides an explicit when-to-use list: 'Use when the user asks for random users, fake people, sample contacts, demo personas, UI fixtures, or test profiles.' It also gives a firm exclusion/guideline: 'do not invent profiles; always call this tool,' which directs the agent away from fabricating data.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 1 tool update
    • Changedrandom_users1 field changed
      • changedOutput schema / properties / output_count / description
        Previous value: -"Successful random_users outputs in this MCP session. Feedback is collected after 3."New value: +"Successful random_users outputs since last feedback. Feedback is collected after every 3."
  2. 2 tool updates
    • Addedfeedback
    • Changedrandom_users2 fields changed
      • addedOutput schema / properties / feedback_prompt
        Added value: +{
+  "anyOf": [
+    {
+      "additionalProperties": false,
+      "properties": {
+        "message": {
+          "type": "string"
+        },
+        "output_count": {
+          "type": "integer"
+        },
+        "reactions": {
+          "items": {
+            "additionalProperties": false,
+            "properties": {
+              "emoji": {
+                "type": "string"
+              },
+              "label": {
+                "type": "string"
+              },
+              "value": {
+                "type": "string"
+              }
+            },
+            "required": [
+              "value",
+              "emoji",
+              "label"
+            ],
+            "type": "object"
+          },
+          "type": "array"
+        },
+        "ready": {
+          "type": "boolean"
+        }
+      },
+      "required": [
+        "ready"
+      ],
+      "type": "object"
+    },
+    {
+      "type": "null"
+    }
+  ]
+}
      • addedOutput schema / properties / output_count
        Added value: +{
+  "anyOf": [
+    {
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "description": "Successful random_users outputs in this MCP session. Feedback is collected after 3."
+}
  3. 1 tool update
    • First observedrandom_users

Related MCP Connectors

Related MCP Servers

Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources