username_enumerateCheck if a username is already registered on 20 major platforms. Identify which social networks and services have an account under that name for OSINT investigations.
Probe ~20 major platforms to see if a username is taken.
| Name | Required | Description | Default |
|---|---|---|---|
| username | Yes |
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations (readOnlyHint, openWorldHint, idempotentHint, destructiveHint=false) already cover the safety profile. The description adds minimal behavior context beyond 'probe' (network activity), but doesn't disclose potential timeouts, rate limits, or what constitutes 'taken' (existence vs. availability). It doesn't contradict annotations, but adds little beyond them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence with no filler. The action and scope are front-loaded ('Probe ~20 major platforms'), making it immediately clear what the tool does. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema (though not shown) and annotations cover safety. The description is short but adequate for a simple one-parameter tool. However, it could mention that it queries multiple platforms and might take longer, or that it returns a simple yes/no per platform. Given the simplicity, it's not seriously incomplete, but a bit more context about the multi-platform behavior would help.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. The single parameter 'username' is self-explanatory, and the description implicitly defines it as the username to probe across platforms. It doesn't add format constraints or clarify edge cases (e.g., case sensitivity), but the name and type string make it understandable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('probe') and a clear resource ('~20 major platforms') to check if a username is taken. It clearly distinguishes itself from sibling tools like github_user_info or reddit_user, which target a single platform.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus the many single-platform sibling tools. It doesn't mention alternatives, conditions, or exclusions. The description implies a broad multi-platform check but doesn't explicitly instruct the agent on when to choose it over a specific platform lookup.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.