Skip to main content
Glama

search_prestashop_hooks

Find PrestaShop hooks by searching with keywords, filtering by type and origin to locate specific functionality in development projects.

Instructions

Search PrestaShop hooks using full-text search.

Args: queries: List of search terms (maximum 3) hook_type: Filter by hook type (display, action) origin: Filter by origin (core, module, theme)

Returns: Formatted search results with hook details

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
queriesYes
hook_typeNo
originNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Implementation Reference

  • Handler function for the 'search_prestashop_hooks' tool. Includes registration via @mcp.tool(), input schema via type hints and docstring, and execution logic that delegates to search_hooks helper and formats results.
    @mcp.tool()
    def search_prestashop_hooks(
        queries: List[str],
        hook_type: Optional[str] = None,
        origin: Optional[str] = None,
    ) -> str:
        """Search PrestaShop hooks using full-text search.
    
        Args:
            queries: List of search terms (maximum 3)
            hook_type: Filter by hook type (display, action)
            origin: Filter by origin (core, module, theme)
    
        Returns:
            Formatted search results with hook details
        """
        if not queries:
            return "Error: Please provide at least one search query"
    
        # Limit to 3 queries
        queries = queries[:3]
    
        logger.info(f"Searching hooks for: {queries}")
        results = search_hooks(queries, hook_type=hook_type, origin=origin, limit=10)
    
        if not results:
            filters = []
            if hook_type:
                filters.append(f"type={hook_type}")
            if origin:
                filters.append(f"origin={origin}")
            filter_str = f" (filters: {', '.join(filters)})" if filters else ""
            return f"No results found for: {', '.join(queries)}{filter_str}"
    
        # Format results
        output = [f"Found {len(results)} hooks for: {', '.join(queries)}\n"]
    
        for i, hook in enumerate(results, 1):
            output.append(f"{i}. **{hook['name']}** ({hook['type']} hook)")
            output.append(f"   Origin: {hook['origin']}")
            output.append(f"   Locations: {hook['locations']}")
    
            if hook.get("description"):
                desc = hook["description"][:150]
                if len(hook["description"]) > 150:
                    desc += "..."
                output.append(f"   Description: {desc}")
    
            if hook.get("aliases"):
                output.append(f"   Aliases: {', '.join(hook['aliases'])}")
    
            if hook.get("snippet"):
                output.append(f"   {hook['snippet']}")
    
            output.append("")
    
        return "\n".join(output)
  • Core search logic using SQLite FTS5 full-text search on hooks table with optional filters for type and origin.
    def search_hooks(
        queries: List[str],
        hook_type: Optional[str] = None,
        origin: Optional[str] = None,
        limit: int = 10,
    ) -> List[Dict]:
        """Search PrestaShop hooks using FTS5.
    
        Args:
            queries: List of search terms
            hook_type: Filter by hook type (display, action)
            origin: Filter by origin (core, module, theme)
            limit: Maximum number of results
    
        Returns:
            List of matching hooks with metadata
        """
        if not queries:
            return []
    
        conn = sqlite3.connect(DB_PATH)
        conn.row_factory = sqlite3.Row
        cursor = conn.cursor()
    
        # Build search query
        search_query = " OR ".join(queries)
    
        # Build WHERE clause for filters
        where_clauses = ["prestashop_docs_fts MATCH ?"]
        params = [search_query]
    
        if hook_type:
            where_clauses.append("hooks.type = ?")
            params.append(hook_type)
    
        if origin:
            where_clauses.append("hooks.origin = ?")
            params.append(origin)
    
        where_clause = " AND ".join(where_clauses)
        params.append(limit)
    
        sql = f"""
            SELECT
                hooks.name,
                hooks.type,
                hooks.origin,
                hooks.locations,
                hooks.description,
                hooks.aliases,
                hooks.github_refs,
                prestashop_docs.path,
                snippet(prestashop_docs_fts, 6, '<mark>', '</mark>', '...', 32) as snippet
            FROM prestashop_docs_fts
            JOIN prestashop_docs ON prestashop_docs.id = prestashop_docs_fts.rowid
            JOIN hooks ON hooks.doc_id = prestashop_docs.id
            WHERE {where_clause}
            ORDER BY rank
            LIMIT ?
        """
    
        cursor.execute(sql, params)
        results = []
    
        for row in cursor.fetchall():
            results.append(
                {
                    "name": row["name"],
                    "type": row["type"],
                    "origin": row["origin"],
                    "locations": row["locations"],
                    "description": row["description"],
                    "aliases": json.loads(row["aliases"]) if row["aliases"] else [],
                    "github_refs": (
                        json.loads(row["github_refs"]) if row["github_refs"] else []
                    ),
                    "path": row["path"],
                    "snippet": row["snippet"],
                }
            )
    
        conn.close()
        return results
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'full-text search' and 'formatted search results,' which gives some context about the search method and output format. However, it lacks critical details: whether this is a read-only operation, any rate limits, authentication requirements, pagination behavior, or what happens if no results are found. For a search tool with zero annotation coverage, this is insufficient.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured and front-loaded: the first sentence states the core purpose, followed by clear sections for Args and Returns. Every sentence earns its place—no redundant information. It's appropriately sized for a search tool with 3 parameters, making it easy to scan and understand quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's moderate complexity (search with filters), no annotations, and an output schema exists (so return values are documented elsewhere), the description is partially complete. It covers the purpose and parameters adequately but lacks behavioral context (e.g., safety, limits) and usage guidelines relative to siblings. The output schema handles return details, but the description should still address when to use this tool and any operational constraints.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the schema provides no parameter descriptions. The description compensates by explaining each parameter: 'queries: List of search terms (maximum 3)', 'hook_type: Filter by hook type (display, action)', and 'origin: Filter by origin (core, module, theme)'. This adds meaningful semantics beyond the bare schema, covering all 3 parameters. However, it doesn't provide examples, format details (e.g., case sensitivity for hook_type), or explain the 'null' default values.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Search PrestaShop hooks using full-text search.' This specifies the verb (search), resource (PrestaShop hooks), and method (full-text search). It distinguishes from siblings like 'list_prestashop_hooks' (which likely lists all hooks without search) and 'get_prestashop_hook' (which likely retrieves a specific hook). However, it doesn't explicitly contrast with 'search_prestashop_docs', which searches documentation rather than hooks.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to choose this over 'list_prestashop_hooks' (e.g., for filtered vs. complete lists) or 'search_prestashop_docs' (e.g., for hooks vs. documentation). The only implied usage is for searching hooks with specific filters, but no explicit when/when-not rules or sibling comparisons are provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/florinel-chis/prestashop-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server