Provides platform-specific code generation and implementation guidance for integrating Searchspring's e-commerce APIs (search, autocomplete, recommendations, tracking) into BigCommerce stores
Provides platform-specific code generation and implementation guidance for integrating Searchspring's e-commerce APIs (search, autocomplete, recommendations, tracking) into Shopify stores
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Searchspring Integration Assistant generate Shopify code for product tracking with beacon API"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol (MCP) server that provides implementation guidance, code validation, and troubleshooting for Searchspring's e-commerce APIs.
Important: This is an integration assistant, not an API proxy. It returns implementation guidance and code examples rather than live API data.
Install and build:
git clone <repo-url>
cd searchspring-api-mcp
npm install && npm run buildConfigure Claude Desktop - Add to your claude_desktop_config.json:
{
"mcpServers": {
"searchspring": {
"command": "node",
"args": ["/absolute/path/to/searchspring-api-mcp/dist/index.js"]
}
}
}Restart Claude Desktop and ask:
"Show me how to implement Searchspring search API"The Searchspring tools will activate automatically - no special commands needed!
Related MCP server: E-commerce API MCP Server
Install dependencies:
npm install
npm run buildStart the server:
npm startNote: SEARCHSPRING_SITE_ID is optional - the LLM can provide example site IDs or ask users for their specific ID when needed.
✅ Implementation Guidance - Step-by-step API integration instructions for all 8 Searchspring APIs
✅ Code Validation - Analyze existing implementations for issues with platform-specific checks
✅ Platform-Specific Code - Generate code for Shopify, BigCommerce, Magento, and 7+ platforms
✅ Troubleshooting - Diagnose common integration problems with targeted solutions
✅ Modern Platform Support - Includes Shopify checkout extensibility and Web Pixel guidance
✅ Documentation Links - Direct links to relevant Searchspring docs
❌ Not an API Proxy - Does not make live API calls or return product data
Tool | Input | Output |
| API name | Complete implementation guide with endpoints, examples, and best practices |
| API name + parameter | Detailed parameter explanation with usage examples and best practices |
Supported APIs: search, autocomplete, suggest, trending, recommendations, finder, beacon, bulk-index
Tool | Input | Output |
| API + platform (+ eventType for tracking) | Platform-specific implementation code |
| Code + codeType (+ platform + issue) | Validation results, warnings, suggestions, and troubleshooting |
Supported Platforms: shopify, bigcommerce, magento1, magento2, miva, commercev3, 3dcart, volusion, javascript, php, python, custom
Supported Code Types: search, autocomplete, suggest, trending, recommendations, finder, beacon, bulk-index, tracking
// Get comprehensive guidance for any API
Input: {"api": "search"}
Output: Complete implementation guide with endpoints, examples, and best practices// Understand specific API parameters
Input: {"api": "search", "parameter": "filters"}
Output: Detailed explanation of filters parameter with examples and best practices// Generate platform-specific implementation
Input: {"api": "beacon", "platform": "shopify", "eventType": "product"}
Output: Ready-to-use Shopify tracking code with Liquid template syntax// Validate existing code and get troubleshooting help
Input: {
"code": "<script>ss.track.product.view({sku: 'ABC'});</script>",
"codeType": "tracking",
"platform": "shopify",
"issue": "Events not showing in analytics"
}
Output: ❌ Missing IntelliSuggest script, ⚠️ No safety check, 🔧 Troubleshooting stepsPlanning → Use searchspring_api_guide to understand API structure and requirements
Deep Dive → Use searchspring_parameter_guide for specific parameter details
Implementation → Use searchspring_code_generator to create platform-specific code
Validation → Use searchspring_code_validator to check your implementation
Troubleshooting → Use validator with specific issues for detailed diagnosis
npm testAdd to your claude_desktop_config.json:
{
"mcpServers": {
"searchspring": {
"command": "node",
"args": ["/absolute/path/to/searchspring-api-mcp/dist/index.js"]
}
}
}Use any MCP-compatible client:
# Start the MCP server
npm start
# Test with mcp-client or similar tools
npx @modelcontextprotocol/inspectorTest individual tools directly:
# Example: Test API guide tool
echo '{"method": "tools/call", "params": {"name": "searchspring_api_guide", "arguments": {"api": "search"}}}' | npm startOnce configured in Claude Desktop, the Searchspring MCP tools are automatically available. No special activation command needed!
Available Tools:
searchspring_api_guide - Get implementation guidance for any API
searchspring_parameter_guide - Get detailed parameter explanations
searchspring_code_generator - Generate platform-specific code
searchspring_code_validator - Validate and troubleshoot existing code
Sample Prompts to Activate Tools:
"Show me how to implement Searchspring search API"
"Generate Shopify tracking code for product views"
"Explain the filters parameter for the search API"
"Validate this search implementation code: [paste code]"
"Create BigCommerce autocomplete code"
"How do I implement bulk indexing for Magento?"Start development server:
npm run devTest API guidance:
Ask Claude: "Show me how to implement Searchspring search API"
Ask Claude: "Generate Shopify tracking code for product views"
Ask Claude: "Validate this search implementation code: [paste code]"
Test platform-specific generation:
Test all platforms: Shopify, BigCommerce, Magento1/2, Miva, CommerceV3, 3dCart, Volusion
Test modern Shopify Web Pixel tracking scenarios
Test bulk indexing guidance (with and without secret key)
Validate cross-references:
Ensure all generated code references match docs.searchspring.com
Verify platform-specific template syntax (Liquid, Handlebars, PHP)
Check that troubleshooting advice matches Zendesk Knowledge Base
Variable | Required | Description |
| ❌ Optional | Your Searchspring site identifier (LLM can provide examples) |
| ❌ Optional | Only needed for bulk indexing guidance |
| ❌ Optional | Request timeout in ms (default: 10000) |
Ready for production deployment with Docker:
# Build the Docker image
docker build -t searchspring-mcp .
# Run without environment variables (LLM will handle site IDs)
docker run searchspring-mcp
# Or with optional environment variables
docker run -e SEARCHSPRING_SITE_ID=your_site_id searchspring-mcpSecurity Features: Non-root user, minimal Alpine base, production-optimized
apiVersion: apps/v1
kind: Deployment
metadata:
name: searchspring-mcp
spec:
replicas: 2
selector:
matchLabels:
app: searchspring-mcp
template:
metadata:
labels:
app: searchspring-mcp
spec:
containers:
- name: searchspring-mcp
image: searchspring-mcp:latest
ports:
- containerPort: 3000
# Environment variables are optional
env:
- name: SEARCHSPRING_TIMEOUT
value: "10000"New Searchspring Customer: Get implementation guidance for search, autocomplete, and tracking Existing Implementation Issues: Validate code and get troubleshooting help Platform Migration: Generate platform-specific tracking code Development Team Onboarding: Understand API structure and best practices Modern Shopify Stores: Get guidance for checkout extensibility and Web Pixel tracking
📖 Documentation: https://docs.searchspring.com/
🎯 Help Center: https://help.searchspring.net/
MIT
Get comprehensive implementation guidance for any Searchspring API
| Name | Required | Description | Default |
|---|---|---|---|
| api | Yes | The Searchspring API to get implementation guidance for |
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 provides 'comprehensive implementation guidance,' but doesn't clarify what that entails—e.g., whether it returns documentation, examples, best practices, or error handling tips. It also omits details like response format, rate limits, authentication needs, or potential side effects, leaving significant gaps for a guidance tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that efficiently conveys the tool's purpose without unnecessary words. It is front-loaded with the core function ('Get comprehensive implementation guidance'), making it easy for an agent to parse quickly. There is no wasted verbiage or structural complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 for effective tool use. It doesn't explain what 'implementation guidance' includes—e.g., whether it's textual documentation, code snippets, or configuration steps—nor does it address potential complexities like API-specific nuances. For a tool with one parameter but no structured output details, more context is needed to guide the agent adequately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the parameter 'api' fully documented via an enum and description. The description adds no additional parameter semantics beyond what the schema provides, such as explaining the significance of each API type or usage examples. With high schema coverage, the baseline score of 3 is appropriate, as the description doesn't enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get comprehensive implementation guidance for any Searchspring API.' It specifies the verb ('Get') and resource ('implementation guidance'), and while it doesn't explicitly distinguish from siblings, it implies a focus on guidance rather than code generation or validation. However, it lacks explicit differentiation from sibling tools like 'searchspring_parameter_guide'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 such as 'searchspring_code_generator' or 'searchspring_parameter_guide', nor does it specify prerequisites, contexts, or exclusions for usage. The agent must infer usage based on the tool name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate implementation code for any Searchspring API with platform-specific examples
| Name | Required | Description | Default |
|---|---|---|---|
| api | Yes | The Searchspring API to generate code for | |
| platform | Yes | Platform or language for code generation | |
| eventType | No | Type of tracking event (for tracking/beacon APIs only) | |
| useCase | No | Specific use case or scenario for the code (optional) |
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 generates code but doesn't explain how (e.g., whether it produces executable snippets, includes error handling, or requires authentication). It also omits details like rate limits, side effects, or output format, which are critical for a code generation tool with no output schema. The description is insufficient for behavioral understanding beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose without unnecessary details. It uses clear language ('Generate implementation code') and specifies key aspects ('any Searchspring API', 'platform-specific examples'). There's no waste or redundancy, making it highly concise and well-structured for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a code generation tool with 4 parameters, no annotations, and no output schema, the description is incomplete. It lacks behavioral details (e.g., how code is formatted, if it includes dependencies), doesn't explain interactions between parameters (e.g., how 'eventType' relates to 'api'), and provides no output information. This leaves significant gaps for an agent to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all parameters well-documented in the schema (e.g., 'api' and 'platform' enums, 'eventType' for specific APIs, 'useCase' as optional). The description adds no additional parameter semantics beyond what the schema provides, such as examples or constraints. Baseline 3 is appropriate since the schema does the heavy lifting, but the description doesn't compensate with extra context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Generate implementation code for any Searchspring API with platform-specific examples.' It specifies the verb ('Generate'), resource ('implementation code'), and scope ('Searchspring API'). However, it doesn't explicitly differentiate from sibling tools like 'searchspring_code_validator' or 'searchspring_api_guide', which likely serve different purposes (validation vs. guidance vs. generation).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 or other contexts where this tool might be preferred or avoided. Usage is implied by the purpose but lacks explicit instructions or exclusions, leaving the agent to infer based on the name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate and troubleshoot Searchspring implementation code
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | JavaScript/HTML code to validate | |
| codeType | Yes | Type of Searchspring implementation being validated | |
| platform | No | E-commerce platform (optional) | |
| issue | No | Specific issue or error message you're experiencing (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool validates and troubleshoots code, implying it performs analysis and returns diagnostic information, but doesn't describe the output format, error handling, or any limitations (e.g., rate limits, supported code complexity). For a validation tool with zero annotation coverage, this leaves significant gaps in understanding how it behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded with the core functionality ('Validate and troubleshoot'), making it immediately clear. Every word earns its place, and there's no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (4 parameters, validation/troubleshooting function) and no output schema, the description is minimally adequate but incomplete. It lacks details on output format, error cases, or behavioral traits, which are important for a validation tool. However, the schema provides good parameter documentation, partially compensating for the description's brevity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds no additional semantic context about parameters beyond what's in the schema (e.g., it doesn't explain how 'codeType' influences validation or what 'platform' affects). With high schema coverage, the baseline score of 3 is appropriate as the description doesn't compensate but doesn't detract either.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as 'Validate and troubleshoot Searchspring implementation code', specifying the action (validate/troubleshoot) and resource (Searchspring implementation code). It distinguishes from sibling tools like 'searchspring_code_generator' (which creates code) and 'searchspring_api_guide' (which provides documentation), though it doesn't explicitly contrast with them in the description text.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 the sibling tools (searchspring_api_guide, searchspring_code_generator, searchspring_parameter_guide) or specify scenarios where validation/troubleshooting is appropriate versus generating code or consulting guides. Usage is implied but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed explanation for specific API parameters, their usage, and best practices
| Name | Required | Description | Default |
|---|---|---|---|
| api | Yes | The Searchspring API containing the parameter | |
| parameter | Yes | The specific parameter to get guidance for (e.g., 'filters', 'sort', 'tags') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool provides 'detailed explanation' and 'best practices,' implying a read-only, informational function, but doesn't specify whether it requires authentication, has rate limits, or what the output format might be. For a tool with zero annotation coverage, this is a significant gap in behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any redundant or extraneous information. It is front-loaded with the core function and appropriately sized for a simple lookup tool, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (2 required parameters, no nested objects) and lack of output schema, the description is adequate but incomplete. It covers the basic purpose but misses behavioral details like authentication needs or output format. With no annotations and no output schema, the description should do more to compensate, but it's minimally viable for this simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with both parameters ('api' and 'parameter') well-documented in the input schema. The description adds minimal value beyond the schema, as it doesn't elaborate on parameter interactions or provide examples beyond what's implied. Given the high schema coverage, a baseline score of 3 is appropriate, as the description doesn't significantly enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get detailed explanation for specific API parameters, their usage, and best practices.' It specifies the verb ('Get detailed explanation') and resource ('specific API parameters'), making the function unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'searchspring_api_guide' or 'searchspring_code_generator,' which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 like 'searchspring_api_guide' or 'searchspring_code_validator,' nor does it specify prerequisites or contexts for usage. This lack of comparative or contextual information leaves the agent with minimal guidance for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
searchspring_api_guidesearchspring_code_generatorsearchspring_code_validatorsearchspring_parameter_guideScored across 4 tools
Each tool has a clearly distinct purpose: one provides general API guidance, another generates code, a third validates code, and the last explains parameters. There is no overlap in functionality, making it easy for an agent to select the right tool without confusion.
All tool names follow a consistent snake_case pattern with a 'searchspring_' prefix and a descriptive suffix (e.g., 'api_guide', 'code_generator'). This uniformity makes the tools predictable and easy to understand at a glance.
With 4 tools, the count is reasonable for an integration assistant focused on Searchspring APIs. It covers key areas like guidance, code generation, validation, and parameter details, though it might benefit from additional tools for broader API operations like testing or deployment.
The tool set covers essential aspects of Searchspring API integration: learning, implementation, validation, and parameter usage. Minor gaps exist, such as lack of tools for direct API calls or error handling, but agents can work around these with the provided tools for most integration tasks.
Provides access to Avalara developer documentation, integration guides, and code examples
Set up and tune ecommerce Search, Recommendations, Pages, Email, Product Agents and Analytics.
Search PayU docs, browse the payment integration catalog, and fetch production-ready code.
Entity resolution — data mapping, SDK code generation, docs search, and error troubleshooting
