Passgen
passgenPassword Gen: Generate strong random passwords + passphrase (offline)
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| q | No |
Output Schema
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
passgenPassword Gen: Generate strong random passwords + passphrase (offline)
| Name | Required | Description | Default |
|---|---|---|---|
| q | No |
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly states 'offline', indicating no network calls, which is a key behavioral trait. It doesn't specify output format or whether different password types can be selected, but the offline nature is a significant disclosure. The description adds value beyond the schema by stating offline capability, which is not evident from the parameter definitions.
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?
The description is extremely concise—a single sentence that front-loads the core purpose ('Generate strong random passwords + passphrase') and adds the offline qualifier. No wasted words, and it's easy to parse at a glance.
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 is simple with only one optional parameter, but the 'q' parameter is completely undocumented. The description provides the core behavior (generation, offline) but doesn't explain how to use the 'q' parameter, whether it accepts a length, number of passwords, or some other configuration. Given the minimal schema, the description should have provided at least a hint about the parameter's meaning.
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?
The input schema has one parameter 'q' with a default of empty string and 0% schema description coverage. The description does not explain what 'q' represents or how to use it. The description says 'Generate strong random passwords + passphrase' but doesn't map this to the 'q' parameter. This is a significant gap since the parameter is undocumented.
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 clearly states it generates strong random passwords and passphrases, and specifies it works offline. It distinguishes itself from sibling tools like passentropy and passwordcheck, which focus on analysis rather than generation. The phrase 'Password Gen' reinforces the purpose.
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?
The description implies when to use it (when you need to generate passwords/passphrases) but doesn't explicitly state when not to use it or mention alternatives. It doesn't clarify whether it supports customization options like length or character sets, which might be relevant for choosing between tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.