MCP server for interacting with the Yogosha bug bounty platform API
Server has 37 tools with basic verb-noun naming (list_, get_, create_, update_, delete_, patch_). However, critical quality gaps severely limit production readiness. All tools lack parameter descriptions, parameters are defined with type and name only, no guidance on format, constraints, or usage. Tool descriptions are minimal (10-30 chars), far below the 50-200 char baseline for LLM optimization. No output schemas documented. Generic dict parameters (asset_data, report_data, vuln_data, patch_data) provide zero guidance on required fields or structure. No error handling guidance, no pagination support despite list tools, no idempotency markers. Security concern: YOGOSHA_API_KEY injected via environment but no audit logging or permission gates. STDIO transport caps protocol readiness at 50 maximum.
Create a new asset for a program. Pass asset_data as a dict with required fields.
Create a new report for a program. Pass report_data as a dict with required fields.
Create a new comment for a report. Pass comment_data as a dict with required fields.
Create a new user. Pass user_data as a dict with required fields.
Create a new vulnerability for a program. Pass vuln_data as a dict with required fields.
Delete an asset from a program.
All dict parameters (asset_data, report_data, vuln_data, patch_data, user_data, comment_data) lack field documentation. LLMs cannot determine required fields, format, or constraints. Agents will hallucinate invalid payloads.
Tool descriptions are 10-30 characters (e.g., 'List all programs.', 'Get a specific program by ID.'). Baseline is 50-200 chars. Descriptions lack context on when to use each tool, what it returns, or dependencies.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 37 | 2026-07-28+ | v2 |
Delete a report from a program.
Delete a comment from a report.
Delete a user by ID.
Delete a vulnerability from a program.
Get a specific asset by ID for a program.
Get a specific invitation by ID for a program.
Get a specific program by ID.
Get a specific report by ID for a program.
Get a specific comment by ID for a report.
Get a specific scope by ID for a program.
Get a specific submission by ID for a program.
Get a specific user by ID.
Get a specific vulnerability by ID for a program.
List all assets for a program.
List all invitations for a program.
List all programs.
List all comments for a report.
List all reports for a program.
List all scopes for a program.
List all submissions for a program.
List all users.
List all vulnerabilities for a program.
Patch (partially update) an asset for a program.
Patch (partially update) a report for a program.
Patch (partially update) a user.
Patch (partially update) a vulnerability for a program.
Update an asset for a program. Pass asset_data as a dict with fields to update.
Update a report for a program. Pass report_data as a dict with fields to update.
Update a comment for a report. Pass comment_data as a dict with fields to update.
Update a user. Pass user_data as a dict with fields to update.
Update a vulnerability for a program. Pass vuln_data as a dict with fields to update.
No output schemas documented. LLMs cannot plan downstream tool calls or extract required fields (e.g., asset_id, report_id) for chaining. Responses are opaque.
No pagination support on list_* tools. No limit, offset, or page parameters. Large result sets will blow context windows and degrade LLM reasoning.
No error handling guidance. Agents receive raw HTTP errors with no recovery hints. No distinction between retryable (timeout), user-fixable (invalid ID), or fatal errors.