Loading ToolBench
Model Context Protocol server for Spryker Package Search. The tool provides search capabilities for the Spryker documentation and packages in Github.
Server has three tools with reasonable structure and clear purposes. All tools have descriptions (10 - 100 chars), input parameters with types, and docstrings. However, there are several issues that prevent a higher score: (1) Parameter descriptions are minimal or missing detail about constraints and usage context. (2) Output schemas are not explicitly documented, tools return text content wrapped in a generic content array, but no schema is published to the LLM. (3) Error handling provides user-facing messages but lacks categorization (retryable vs. fatal) and recovery guidance. (4) No tool annotations (readOnlyHint, etc.) despite all being read-only. (5) The 'organisations' parameter in two tools lacks an enum constraint, LLMs must guess which orgs are valid from the description alone. This violates the pattern:constrained-input rule. See per-tool scores below.
To search in Spryker documentation by query
To search code in Spryker GitHub repositories
To search the Spryker package repository in Github
Parameter 'organisations' in search_spryker_packages and search_spryker_package_code lacks enum constraint. Description lists valid values ['spryker', 'spryker-eco', 'spryker-sdk', 'spryker-shop'] as text only. LLMs cannot parse this reliably and may invent invalid org names.
Output schema is undocumented. All tools return {content: [{type: 'text', text: string}]} but this structure is inferred from code, not declared in the tool schema. LLMs have no formal specification of what they will receive, limiting downstream planning.
Parameter 'maxTokensSize' in search_spryker_documentation has a reasonable description but the constraint reasoning is unclear. Description says 'recommended a half of context window and minimum 16000', this is context-dependent advice that LLMs will misinterpret. Should clarify: 'Token limit for returned content to prevent context exhaustion. Recommended: 32000 (half of 64k context). Minimum: 16000.'
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 55 | <=2025-11-25 | v2 |
| 2026-03-09 | D | 59 | - | v1 |
Error handling returns user-facing messages ('Error performing search: <error.message>') but does not categorize errors or guide recovery. A network timeout is not retryable the same way a malformed query is. LLMs receive no recovery hints.
Tool annotations are missing. All three tools are read-only and should declare readOnlyHint: true. This helps agents understand which tools are safe to call speculatively and aids permission planning.
Parameter descriptions are terse and lack actionable detail. E.g., 'The natural language query to search in Github' for search_spryker_packages does not explain: What kind of queries work best? Should I use package names, problems I'm solving, or GitHub issue keywords? Are there keywords that fail? This forces LLMs to guess.