Click on "Install 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., "@product-search-mcp-server search for Avery labels in stock"
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.
An MCP server that exposes the SF Supplies product search (the Typesense-backed
website search API) to an LLM tool loop. It is a sibling of mssql-mcp-server
and uses the same transport/auth/deploy pattern, so the internal chatbot can
bridge both servers at once.
Tool | What it does |
| Runs a search against |
| Fast typeahead/autocomplete ( |
| Returns the facets (filterable attributes and their values + counts) available for a query/category — so the model knows what it can pass to |
The filters argument maps facet field names to arrays of values, matching the
API's attributeFilter, e.g.:
{"Brand": ["Avery"], "Color": ["Plum"], "Size": ["15\" x 10 Yards"]}Related MCP server: MCP Merchant Scout
pipenv install
pipenv run python -m product_search_mcp_servercp .env.deploy.example .env.deploy # set MCP_AUTH_TOKEN (openssl rand -hex 32)
docker compose -f docker-compose.deploy.yml up -d --buildConsumers connect to http://<host>:8001/mcp with header
Authorization: Bearer <MCP_AUTH_TOKEN>. Defaults to port 8001 to avoid
clashing with the MSSQL MCP server on 8000.
examples/chatbot_bridge.py shows the client-side bridge the chatbot uses.
Env var | Default | Purpose |
|
|
|
| — | Required bearer token in |
|
| Dev-only: serve HTTP with no auth |
|
| HTTP bind (container) |
|
| Results/filtering endpoint |
|
| Typeahead/autocomplete endpoint |
|
| Product page link template — verify the path |
|
| HTTP timeout (seconds) |
| — | Optional, only if the API gets locked down |
Discover the filterable attributes (facets) available for a given search/category, with each value and how many products have it. Use this to learn what you can pass to search_products' 'filters' argument and to suggest refinements.
| Name | Required | Description | Default |
|---|---|---|---|
| search | No | Free-text query to scope the facets (optional). | |
| filters | No | Attribute filters to narrow results. Keys are facet field names (see list_product_filters), values are arrays of allowed values, e.g. {"Brand": ["Avery"], "Color": ["Plum"], "Size": ["15\" x 10 Yards"]}. Multiple values for one field are OR-ed; different fields are AND-ed. | |
| category_slug | No | Restrict facets to a category slug (optional). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It implies a read-only operation (discovering facets) but does not explicitly state that it is non-destructive or any authorization requirements. This is adequate but not thorough.
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 concise: two sentences with clear front-loading. No superfluous words, each sentence serves a purpose.
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 no output schema, the description adequately describes the output (values and counts). It also explains how the output relates to another tool. Missing details like pagination or limits, but for a discovery tool this is sufficient.
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?
All three parameters have schema descriptions (100% coverage), so the schema already explains parameter meaning. The description adds context about the output format but does not provide deeper parameter semantics beyond the schema.
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 explicitly states the tool's function: to discover filterable attributes (facets) for a given search or category, including counts. It also connects to a sibling tool (search_products), distinguishing it from search_products and suggest_products.
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 advises using this tool to learn what to pass to search_products' 'filters' argument, providing clear context. It does not explicitly state when not to use, but the usage scenario is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the SF Supplies product catalog (vinyl, films, signage supplies, etc.). Returns matching products with their name, page URL, stock status, product status, and attributes (Brand, Color, Size, Material, Finish, Series, …). Use the optional 'filters' to narrow by attribute — call list_product_filters first if you need to know which attributes/values are available. Two distinct availability signals: 'in stock' reflects inventoryQty — whether the item is ACTUALLY in stock in the warehouse right now (yes/no). 'status' is the catalog classification: StockItem (normally stocked), InHouse (made/held in house), NonStock (orderable, not stocked), Discontinued (no longer offered), Development (not yet released), or Null. A product can be a StockItem yet currently out of stock — when asked about availability, use 'in stock' (inventoryQty), not 'status'. To FILTER by these, pass 'in_stock' (true = only in-stock, false = only out-of-stock) and/or 'product_status'.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Zero-based page index (default 0). | |
| search | Yes | Free-text query, e.g. 'Avery translucent vinyl'. May be empty to browse by filters/category alone. | |
| filters | No | Attribute filters to narrow results. Keys are facet field names (see list_product_filters), values are arrays of allowed values, e.g. {"Brand": ["Avery"], "Color": ["Plum"], "Size": ["15\" x 10 Yards"]}. Multiple values for one field are OR-ed; different fields are AND-ed. | |
| in_stock | No | Filter by real warehouse availability: true = only items currently in stock, false = only out-of-stock. Omit to include both. | |
| page_size | No | Results per page (1-50, default 8). | |
| sort_column | No | Column to sort by (optional; leave empty for relevance). | |
| category_slug | No | Restrict to a category by its slug (optional). | |
| product_status | No | Filter to one catalog status (StockItem, InHouse, NonStock, Discontinued, Development). Omit for all. Distinct from in_stock — a StockItem can be out of stock. | |
| sort_direction | No | 'asc' or 'desc' (optional). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so description carries full burden. Explains two availability signals ('in stock' vs. 'product status'), filter semantics, and that empty search browses. Lacks details on rate limits, auth, or pagination behavior.
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?
While informative, the description is a single dense paragraph. Could be more scannable with bullet points or sections, but sentences are purposeful and front-loaded with purpose.
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 9 parameters, 100% schema coverage, no output schema, and two siblings, the description is comprehensive. Covers filter mechanics, stock/status distinction, and suggests a prerequisite tool. Minor omission: no mention of sort behavior or pagination beyond defaults.
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 coverage is 100%, yet description adds significant value: explains filters structure with examples, clarifies in_stock and product_status enum meanings, and notes default values. Goes well beyond bare schema.
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?
Explicitly states it searches the SF Supplies product catalog, lists return fields, and distinguishes stock vs. status. Mentions sibling tool list_product_filters for attribute discovery.
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?
Advises calling list_product_filters first for available attributes, explains when to use in_stock vs. product_status, and clarifies filter logic (OR/AND). Does not explicitly contrast with suggest_products.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fast typeahead/autocomplete lookup (the search-bar suggester). Given a partial query it returns matching product NAMES (and page URLs) — lightweight, no attributes or filters. Use it to resolve a vague or partial term to concrete product names, then call search_products with the chosen term for full details.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max suggestions to return (1-25, default 10). | |
| query | Yes | Partial or full search text, e.g. 'hp750'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description discloses lightweight behavior, no attributes/filters, and the nature of returned data. Could mention read-only behavior more explicitly, but sufficient.
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?
Two sentences with no waste; front-loaded with purpose and key constraints.
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?
No output schema, but description mentions returns names and URLs; missing details on error cases or empty results, but adequate for a 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?
Schema covers 100% with descriptions; description adds context that it works with partial queries and returns names/URLs, enhancing 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?
Description clearly states it's a typeahead/autocomplete lookup returning product names and page URLs, distinguishing it from sibling tool search_products.
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?
Explicitly says use it to resolve vague terms to concrete names, then call search_products for full details, providing clear when-to-use guidance.
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. Dates show when Glama detected each change.
v0.1.0list_product_filterssearch_productssuggest_productsEach tool has a clear, distinct purpose: list_product_filters discovers filterable attributes, search_products performs full catalog searches with filters, and suggest_products provides lightweight autocomplete. No overlap in functionality.
All tool names follow a consistent verb_noun pattern (list_product_filters, search_products, suggest_products), making them predictable and easy to understand.
Three tools is an ideal size for a product search server, covering the essential operations (discover filters, search with filters, autocomplete) without being too few or overly numerous.
The tool set provides a complete surface for product search: discovering available filters, performing full searches with filtering, and quick autocomplete. No obvious gaps for the intended domain.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Flight search MCP server providing search, pagination, and itinerary details for AI assistants.
An MCP server that provides an API to LLMs to manage their JumpCloud resources.
Capability registry for the agentic economy. Semantic search over verified MCP server listings.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/sfsupplies/internal-product-search-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
