Loading ToolBench
MCP server for interacting with Triple Whale API to access e-commerce performance data
Single tool 'moby' has critical definition gaps. Tool name lacks action verb (should be 'ask_moby' or 'query_moby'). Description is 1,247 chars, far exceeds 1,024 char baseline and embeds raw OpenAPI spec instead of LLM-optimized prose. Input schema visible but parameters lack proper type definitions in the schema object itself (only in description text). No output schema formally documented in the tool definition. Error handling guidance exists in description but is buried in XML tags, not structured for agent consumption. Tool does not follow verb_noun naming convention.
moby tool helps users access e-commerce performance data. the tool prompts the user to enter their **shopId**, which is then used for tool as input, shopId is must for this tool. <response-handling> <response-schema> openapi: 3.1.0 info: title: Triple Whale GPT API description: Access e-commerce performance data using the Triple Whale Moby API. version: 1.0.0 servers: - url: https://api.triplewhale.com description: Production server paths: /willy/moby-chat: post: operationId: answerMobyQuestion summary: Get an answer from the Triple Whale Moby API. description: Sends a user question to the API along with their shop ID and API key. security: - ApiKeyAuth: [] requestBody: required: true content: application/json: schema: $ref: "#/components/schemas/QuestionRequest" responses: "200": description: Successfully retrieved the answer. content: application/json: schema: $ref: "#/components/schemas/SimplifiedMobyResponse" "400": description: Bad request (e.g., missing parameters). "403": description: Unauthorized, invalid API key. "500": description: Internal server error. components: securitySchemes: ApiKeyAuth: type: apiKey in: header name: x-api-key description: User-provided API key in UUID format. schemas: QuestionRequest: type: object required: - shopId - question properties: shopId: type: string description: store ID example: example-store.com question: type: string description: The question to ask Triple Whale. example: What is my ROAS for Facebook campaigns in the last 60 days? SimplifiedMobyResponse: type: object properties: isError: type: boolean description: Indicates if the API request resulted in an error. error: type: string nullable: true description: Error message if `isError` is true. responses: type: array description: List of responses from the API. items: $ref: "#/components/schemas/SimplifiedResponse" assistantConclusion: type: string description: Final summary from the assistant. SimplifiedResponse: type: object properties: isError: type: boolean errorMsg: type: string nullable: true question: type: string answer: type: array description: The structured answer. items: type: object additionalProperties: oneOf: - type: string - type: number - type: "null" assistant: type: string </response-schema> The API returns a **SimplifiedMobyResponse** object structured as follows: ```ts export type SimplifiedResponse = { isError: boolean; errorMsg?: string; question: string; answer: Record<string, string | number | null>[]; assistant: string; }; export type SimplifiedMobyResponse = { isError: boolean; error?: string; responses: SimplifiedResponse[]; assistantConclusion: string; }; ``` - The tool parses the **responses** array and presents answers sequentially. - If `isError` is `true` in any response, the entire message is considered an error, and the error message is displayed. - The `assistantConclusion` is included at the end to summarize the results. - **For each valid response:** - Show the **question**. - Present the **answer** data in a clear, structured format. - Mention that the data is available in the recommended visualization format (if provided in `assistant`). - If similar reports are suggested in the `assistant`, provide links. - Ask if the user needs further assistance using the assistantConclusion from the response. </response-handling> <error_handling> - If `isError: true`, display the error message to the user. - If the API returns `403 Unauthorized`, inform the user: "Invalid credentials. Please check your settings." - If the `shopId` is missing, prompt the user to enter it. - For other errors, respond with: "Something went wrong. Please try again later." If the API return 401 it means the API key is invalid, this means the api ket doesn't have access to the shop so just say that api key is expired or doesn't have access to the shop. </error_handling>
Tool name 'moby' does not start with action verb. Should be 'ask_moby', 'query_moby', or 'get_ecommerce_data' to signal intent to LLM.
Description is 1,247 characters, exceeds 1,024 char baseline by 22%. Embeds raw OpenAPI spec and XML error-handling tags instead of concise LLM-optimized prose. LLMs waste tokens parsing boilerplate.
Input schema in src/tools.ts references 'mobyInputSchema' from toolsSchema.js but that file is not provided. Cannot verify parameter types, constraints, or descriptions are properly declared in JSON Schema format.
Output schema documented only in description text (SimplifiedMobyResponse type). Not formally declared in tool definition. LLMs cannot reliably parse unstructured schema descriptions to plan downstream calls.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 35 | 2026-07-28+ | v2 |
API key (TRIPLEWHALE_API_KEY) is injected server-side (good), but description does not clarify that shopId is the only required user input. LLM may attempt to pass credentials as parameters.