Loading ToolBench
MCP server for dispatching influencer outreach and seeding campaigns with personalization and tracking capabilities
This MCP server has critical deficiencies that make it unsuitable for production. The single tool 'execute_skill_action' has a reasonable name and parameter schema, but the implementation is fundamentally broken: the mcp_server.py file contains only a static JSON print statement with hardcoded metadata and no actual tool registration, request handling, or protocol implementation. The server does not respond to MCP requests, does not parse tool invocations, and does not execute the client code. The parameter descriptions are minimal (10-15 chars) and fall well below the 34-char baseline for tool descriptions. No output schema is documented. The tool's actual implementation is a hardcoded mock in client.py that always returns the same response structure regardless of input, making it non-functional for real campaign dispatch. There is no error handling, no input validation, and no evidence of MCP protocol compliance beyond a single print statement.
Execute influencer outreach and seeding campaign dispatch actions
No actual MCP protocol implementation. The mcp_server.py file contains only a hardcoded JSON print statement and does not implement the MCP request-response cycle. No code reads from stdin, parses MCP messages, dispatches to tools, or writes responses to stdout.
Tool description is only 80 characters long and provides minimal context. It does not explain WHAT the tool does, WHEN to use it, WHAT the output represents, or any prerequisites. Baseline for tool descriptions is 194 chars; this is well below the minimum 34-char threshold that triggers hard scoring penalties.
No output schema is documented. The mock client.py returns an unspecified JSON object with fields like 'dispatch_batch_id', 'delivery_success_rate_pct', 'campaign_tracker_portal_url', but no schema is provided to the MCP server. LLMs cannot plan downstream tool calls without knowing the output structure.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 31 | 2026-07-28+ | v2 |
Parameter descriptions are trivial (5-40 chars): 'Name of the campaign', 'Number of creators to reach out to', 'Level of personalization for outreach messages'. These do not explain constraints, formats, valid ranges, or dependencies. Baseline for param annotations is 72 chars; these are 50% shorter.
Tool implementation is a non-functional mock. The client.py dispatch_outreach_sequence() method returns a hardcoded response that ignores all input parameters. Passing different campaign_name or creators_count values does not change the output, making the tool unsuitable for real use.
No error handling or recovery guidance. The mock implementation cannot fail, and there are no error messages, retryability hints, or actionable recovery paths for LLMs. If this tool is ever connected to a real API, failures will be silent or unhelpful.
No parameter validation or constraints. The 'creators_count' parameter accepts any integer with no documented minimum, maximum, or range. 'personalization_depth' has an enum constraint in the schema (DEEP_RECENT_VIDEO_ANCHOR) but the schema only lists one valid value, making it functionally a required constant rather than a meaningful choice.
Tool performs an irreversible operation (dispatch campaign emails) but has no confirmation, dry-run, or preview step. An LLM could accidentally send outreach to thousands of creators without explicit user confirmation.
Default parameter values are problematic. 'creators_count' defaults to 50, which is a large number that could trigger unintended mass outreach if the LLM omits the parameter. Defaults that cause side effects should be explicit or absent.