Skip to main content
Glama
vitaliiivanovspryker

Spryker Package Search Tool

search_spryker_documentation_path

Find Spryker documentation URLs by entering natural language queries to locate specific help resources and technical guides.

Instructions

To search Spryker documentation path urls by query

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
queryYesThe natural language query to search Spryker documentation path url

Implementation Reference

  • The handler function searchSprykerDocs that implements the core logic of the tool: normalizes query, builds GitHub search for spryker-docs MD files, fetches results via searchGitHubCode, formats with formatDocsResults, and returns markdown text.
    export const searchSprykerDocs = async ({query}) => {
        logger.info(`Received searchSprykerDocs request`, { query });
    
        try {
            const normalizedQuery = normalizeQuery(query);
    
            // Fixed search scope: only spryker/spryker-docs repository with MD files
            const githubQuery = `${normalizedQuery} repo:spryker/spryker-docs path:docs/ in:file extension:md`;
    
            logger.info(`Performing GitHub docs search`, { query: githubQuery });
    
            const searchResults = await searchGitHubCode(githubQuery);
    
            logger.info(`GitHub docs search completed`, {
                resultCount: searchResults.items ? searchResults.items.length : 0,
                totalCount: searchResults.total_count
            });
    
            // Format results similar to code search but with a different header
            const formattedText = formatDocsResults(searchResults.items);
            logger.debug(`Docs search results formatted for display`);
    
            return {
                content: [{
                    type: `text`,
                    text: formattedText
                }]
            };
        } catch (error) {
            logger.error(`Error in docs search: ${error.message}`, {
                error,
                stack: error.stack
            });
    
            return {
                content: [{
                    type: `text`,
                    text: `Error performing docs search: ${error.message}`
                }]
            };
        }
    }
  • src/index.js:72-83 (registration)
    Tool registration in the MCP server, including the tool name, description, input schema (Zod validation for query parameter), and reference to the handler function.
    server.tool(
        `search_spryker_documentation_path`,
        `To search Spryker documentation path urls by query`,
        {
            query: z
                .string()
                .max(120)
                .min(5)
                .describe(`The natural language query to search Spryker documentation path url`)
        },
        searchSprykerDocs
    );
  • Input schema definition using Zod for the query parameter: string between 5-120 chars.
        query: z
            .string()
            .max(120)
            .min(5)
            .describe(`The natural language query to search Spryker documentation path url`)
    },
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 states the tool searches documentation path URLs but doesn't describe what the search returns (e.g., list of URLs, relevance scores, pagination), how results are ranked, or any limitations (e.g., rate limits, authentication needs). This leaves critical behavioral aspects unspecified.

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 a single, efficient sentence that directly states the tool's function without unnecessary words. It's front-loaded with the core purpose and appropriately sized for a simple search tool, earning full marks for conciseness.

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

Completeness2/5

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

Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., search results format), behavioral traits like search scope or limitations, or how it differs from sibling tools. For a search tool with no structured output documentation, this leaves significant gaps for an AI agent.

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?

The input schema has 100% description coverage, with the 'query' parameter documented as 'The natural language query to search Spryker documentation path url'. The description adds no additional parameter semantics beyond what the schema provides, so it meets the baseline for high schema coverage without compensating value.

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 Spryker documentation path urls by query'. It specifies the verb (search), resource (Spryker documentation path urls), and mechanism (by query). However, it doesn't explicitly differentiate from sibling tools like 'search_spryker_package_code' or 'search_spryker_packages', which likely search different resources.

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 sibling tools, prerequisites, or specific contexts where this search is appropriate. The agent must infer usage based on the name alone, which is insufficient for optimal tool selection.

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/vitaliiivanovspryker/spryker-package-search-mcp'

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