Static source inference · medium confidence · detected: Logging
Deprecated protocol patterns detected
Summary
The server defines 6 tools for PrestaShop documentation and hook searching. Tool names follow the verb_noun pattern (search_*, get_*, list_*) which is correct. However, parameter descriptions are minimal or absent in the source code visible. Input schemas are present but descriptions for individual parameters are sparse. Output schemas are not documented, the code returns formatted strings rather than structured objects. Error handling exists but lacks recovery guidance. The visible code shows tool implementations but parameter-level descriptions are underspecified.
Tools (6)
get_prestashop_docread onlysource verified68/100
Get the full content of a specific PrestaShop documentation file.
get_prestashop_hookread onlysource verified72/100
Get complete documentation for a specific PrestaShop hook.
Output schemas not documented. All tools return plain strings (formatted markdown/text) rather than structured objects. LLMs cannot parse or plan downstream operations on unstructured text responses. No documented return types for any tool.
Parameter descriptions lack detail and constraints. Parameters like 'hook_type' have minimal description ('Filter by hook type (display, action)') but no specification of valid enum values, whether they are case-sensitive, or what happens if an invalid value is passed. The 'queries' parameter in search_prestashop_hooks states 'maximum 3' but this is not a machine-readable constraint.
Convert all tools to return structured JSON objects instead of formatted strings. Define explicit response schemas with typed fields. Example: search_prestashop_hooks() should return {results: [{name, type, origin, description, locations, aliases, snippet}], total_count: number, has_more: boolean} instead of a formatted string.
Add enum constraints to parameters. For hook_type, define as enum: ['display', 'action']. For origin, define as enum: ['core', 'module', 'theme']. For doc_type, define as enum: ['hook', 'guide', 'tutorial', 'api', 'reference', 'component', 'faq', 'general']. For category, define as enum: ['basics', 'development', 'modules', 'themes', 'etc.']. Make these machine-readable in the schema, not just in descriptions.
Implement pagination for list tools. Add parameters: limit (1-100, default 20), offset (default 0). Return {items: [...], total_count: number, offset: number, limit: number, has_more: boolean}. This allows agents to progressively fetch results without hardcoded truncation.
Enhance error messages with recovery guidance. Instead of 'Hook not found', return 'Hook "displayHeader" not found. Did you mean: displayHeaderCategory, displayProductPriceBlock? Try list_prestashop_hooks() to see all available hooks.' This matches the recovery-guide pattern.
Add validation for the 'queries' parameter in search_prestashop_hooks. Document that max 3 queries is enforced, and return a clear error if more are provided: 'Maximum 3 search queries allowed; you provided 5. Using first 3: [...]' instead of silently truncating.
Spec posture evidence
Inferred effective spec: <=2025-11-25.
Relies on Logging (deprecated) - log to stderr or use OpenTelemetry
Error handling returns plain strings without recovery guidance. Examples: 'Hook not found' with generic suggestion to call list_prestashop_hooks(), or 'No results found' without suggestions for similar terms or alternative searches. No categorization of errors (retryable vs user-fixable vs fatal).
Pagination not implemented for list tools. list_prestashop_hooks() and list_prestashop_docs() have no limit or offset parameters. The code shows hardcoded limits (20 items) with '... and N more' text, forcing multiple agent calls to see full results. No continuation tokens or next_cursor provided.
No input validation or constraint enforcement. The code checks 'if not queries' in search_prestashop_hooks but does not validate hook_type or origin against known values. Invalid filter values will silently produce empty results rather than actionable error messages.
Document all output schemas explicitly. Add docstring sections describing the return type and field structure for each tool. Use JSON Schema format to make it machine-readable.
Add parameter descriptions for all filters. For each optional parameter (hook_type, origin, doc_type, category), specify: valid values, default behavior if omitted, case sensitivity, and what happens with invalid input.
Consider adding a 'get_hook_stats' or similar tool to answer aggregate questions ('How many display hooks exist?') without requiring full list operations, improving agent efficiency.