Lists test credentials and access requests for a bug bounty program without exposing sensitive login details. Provide a program slug to retrieve credential metadata and access statuses.
Liste les credentials de test et demandes d'accès d'un programme. Les logins, e-mails et mots de passe ne sont jamais renvoyés.
| Name | Required | Description | Default |
|---|---|---|---|
| program_slug | Yes |
Changes observed during successful MCP inspections.
v0.3.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds a useful non-obvious guarantee: logins, emails, and passwords are never returned, which helps an agent set correct expectations about the output and avoid assuming secrets are included.
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?
Two short sentences with no filler. The main purpose is front-loaded, and the redaction warning is placed second where it reinforces behavior without bloating the description.
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?
With one required parameter, strong read-only annotations, and no output schema, the description covers what the tool does and the key output limitation. It does not detail the exact return shape or statuses of access requests, but that is not necessary for correct invocation.
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 coverage is 0%, so the description should compensate. It ties the slug to a specific program ('d'un programme') but does not explain how to obtain the slug or provide an example. Since there is only one required parameter with a self-explanatory name, this is minimally adequate.
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 ('Liste') and a unique resource ('credentials de test et demandes d'accès d'un programme'), which clearly distinguishes it from sibling tools like get_program or list_accessible_programs. The scope is per-program and the purpose is immediately understandable.
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 this is for listing credential-related data for a single identified program, and program_slug is required. However, it does not explicitly state when to prefer this tool over siblings or mention any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.