Loading ToolBench
Decision-intent marketing via AI-generated social media comments. Generates authentic, intent-driven marketing comments that blend naturally into social media conversations across multiple platforms.
This server presents a marketing comment generation tool with moderate schema quality but significant description gaps and no visible MCP server implementation. The three tools are defined in Python client code (client.py, example_usage.py), not as an actual MCP server with tool registration endpoints. Schema definitions are present and reasonably constrained for generate_comment (enum platforms/tones, typed arrays), but descriptions are generic and lack context for LLM tool selection. The batch_generate tool lacks parameter-level descriptions entirely. Most critically, there is no evidence of MCP protocol compliance: no JSON-RPC handlers, no initialize response, no tool/resource/prompt endpoints. The code appears to be a standalone Python SDK, not an MCP server. If this is intended to wrap as an MCP server, the transport and protocol implementation are completely absent.
Run generate_comment for multiple campaigns at once.
Generate marketing comment variants for a given product and platform.
Simulates calling an LLM using the skill definition and input data to generate a marketing reply.
No MCP server implementation detected. Source contains only a Python client SDK (AiCommentClient class) with no JSON-RPC message handlers, initialize response, or tool registration endpoints. Cannot verify this is actually an MCP server.
batch_generate lacks parameter-level documentation. The 'campaigns' parameter accepts a list of dicts but provides no schema for the dict structure, no description of required keys, and no validation guidance. LLMs cannot infer that each dict should match generate_comment params.
generate_marketing_reply tool definition is poorly structured. The 'input_data' parameter is an untyped object with no schema, no required keys list, and no description of what keys should be present. Function signature shows it exists in example_usage.py but is not formally registered as a tool endpoint.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 39 | 2026-07-28+ | v2 |
Tool descriptions are generic and lack LLM-optimized context. 'Generate marketing comment variants for a given product and platform' (58 chars) is functional but does not explain WHEN to use this vs other tools, WHAT the output structure is, or any prerequisites. Descriptions should be 50-200 chars with explicit decision context.
No output schema documentation. Tools return dicts (e.g., generate_comment returns {platform, tone, product, product_url, variants}) but there is no schema documenting the structure, field types, or what downstream tools should expect. LLMs cannot plan multi-step calls without knowing output shape.
No error handling or recovery guidance. The _generate_via_openai method can fail (HTTP timeout, JSON parse failure, API error) but tools do not document expected error types, how to retry, or what the LLM should do if a call fails. No try/except guards or error classification.
Sensitive data in parameters: product_url and thread_context accept arbitrary strings without validation. No guidance on what happens if URLs contain sensitive data. API keys are passed via environment variables (good), but server does not document secret injection or least-privilege patterns.
Transport and protocol unknown. README or pyproject.toml not provided in source. No evidence of stdio, HTTP, or SSE transport. Code is a standalone Python SDK, if intended to be an MCP server, the transport layer is missing entirely.