Loading ToolBench
Model Context Protocol server for Spryker Package Search. The tool provides search capabilities for the Spryker packages in Github.
Three tools are explicitly registered with Zod schemas and descriptions in src/index.js. All tools have proper input parameter validation (query minLength/maxLength, optional organizations array). Descriptions are present but generic and lack actionable guidance. Parameter descriptions exist but are minimal. Output schemas are not documented, tools return unstructured text responses with no field definitions. Error handling returns plain error messages without recovery guidance or categorization. The server lacks composition guidance (when to use each tool, dependencies between them). No structured output formatting beyond text wrapping of GitHub results.
To search Spryker documentation path urls by query
To search code in Spryker GitHub repositories
To search the Spryker package repository in Github
Output schemas are not documented. Tools return text responses with no field structure defined, forcing LLMs to parse unstructured text. Users cannot predict what fields or data structure they receive.
Error handling returns plain error messages without recovery guidance. Errors like 'Error performing search: <message>' give the LLM no actionable next step. No distinction between retryable, user-fixable, and fatal errors.
Tool descriptions are generic and lack composition guidance. Descriptions do not explain WHEN to use each tool vs the others, creating ambiguity. E.g., 'To search code in Spryker GitHub repositories' does not distinguish from 'To search the Spryker package repository' for an LLM deciding which to invoke.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 49 | <=2025-11-25 | v2 |
| 2026-03-09 | D | 52 | - | v1 |
Parameter descriptions are minimal and lack format constraints. 'The natural language query to search in Github' does not explain acceptable input style, typical length, or examples of good vs bad queries. Constraint-only descriptions waste opportunity to guide LLM input formation.
organisations parameter accepts a free-form string array but description lists valid values as a string ('spryker', 'spryker-eco', 'spryker-sdk', 'spryker-shop'). Should be declared as enum constraint in schema for machine-parseable validation, not just description prose.
No pagination support. Tools return all GitHub search results as text. If a query matches 100+ repositories or code snippets, the entire result is dumped into context, potentially exhausting the window. No limit parameter, no next_cursor, no total_count in response structure.