Which integrations are available for this server?

Provides integration with Shopify through Apify Actors, enabling automated data extraction and interaction with Shopify stores.

How do I use Product Data Tools MCP Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Product Data Tools MCP Server scrape product details from Amazon for iPhone 15" 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.

Product Data Tools MCP Server

by ABAKHAR721

Overview Schema Related Servers Score Discussions

Python

first install dependencies using uv package

uv add requirements.txt

you can use

python -m pip install requirements.txt

Basic MCP Project Setup

This repository contains the basic setup steps for a project utilizing uv for dependency management and environment setup, and configuring tools to be used within an MCP (Multi-tool Control Panel) environment, potentially like Claude Desktop.

Prerequisites

Python 3.7+ (recommended)
Network access to download uv and project dependencies.

Related MCP server: crawl4ai-mcp

Installation

This section guides you through setting up the uv tool and initializing your project environment.

1. Install `uv`

uv is used for managing Python environments and dependencies efficiently. Choose the command corresponding to your operating system.

Windows (PowerShell):

powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"

macOS / Linux (Bash):

curl -LsSf https://astral.sh/uv/install.sh | sh

After running the installation command, it's crucial to restart your terminal or command prompt to ensure the uv command is recognized in your PATH.

2. Project Setup

Now, let's create the project directory, set up the virtual environment, install necessary dependencies, and create the main server file.

macOS / Linux:

# Create a new directory for our project (e.g., 'weather')
uv init weather
# Navigate into the project directory
cd weather

# Create a virtual environment inside the project folder
uv venv
# Activate the virtual environment
source .venv/bin/activate

# Install project dependencies.
# mcp[cli] requires extra dependencies for the command-line interface.
uv add "mcp[cli]" httpx

# Create our server file (where your application code will reside)
touch weather.py

Windows (Command Prompt or PowerShell):

# Create a new directory for our project (e.g., 'weather')
uv init weather
# Navigate into the project directory
cd weather

# Create a virtual environment inside the project folder
uv venv
# Activate the virtual environment
.venv\Scripts\activate

# Install project dependencies.
# mcp[cli] requires extra dependencies for the command-line interface.
uv add mcp[cli] httpx

# Create our server file (where your application code will reside)
new-item weather.py

At this point, you have a project directory (j), a dedicated virtual environment (.venv), installed libraries (mcp[cli], httpx), and an empty file (``) where you can add your application logic.

Configuration (for Claude Desktop MCP)

If you are using this project with Claude Desktop or a similar MCP tool, you will need to configure it to recognize and run your tools. Below is an example of a configuration structure that defines how different tools are launched.

Note: The exact location and format of the MCP configuration file depend on the specific MCP software you are using (e.g., Claude Desktop's settings). The following is the content of a potential configuration section:

{
  "mcpServers": {
    "product_data_tools": {
      "command": "uv",
      "args": [
        "--directory",
        "C:\\Users\\asus4\\OneDrive\\Bureau\\mcp-Project\\project\\mcp-project",
        "run",
        "server.py"
      ]
    },
    "Bright Data": {
      "command": "npx",
      "args": ["@brightdata/mcp"],
      "env": {
        "API_TOKEN": "api_token",
        "WEB_UNLOCKER_ZONE": "unlocker_zone",
        "BROWSER_ZONE":"your BROWSER_ZONE"
      }
    },
    "actors-mcp-server": {
      "command": "npx",
      "args": [
        "-y",
        "@apify/actors-mcp-server",
        "--actors",
        "autofacts/shopify"
      ],
      "env": {
        "APIFY_TOKEN": "api_token"
      }
    }
  }
}

product_data_tools: This entry defines a tool that runs your Python server file (server.py, though in our setup we created weather.py - you'll need to adjust the args if you stick to weather.py). It uses uv run to execute the file within the virtual environment managed by uv. Remember to update the --directory path to the actual location of your project directory (weather) on your system.
Bright Data: Configures a tool that runs a Bright Data MCP server using npx. Requires specific environment variables for authentication and zone selection.
actors-mcp-server: Configures a tool that runs an Apify Actors MCP server using npx. Requires an API token.

After adding or updating the configuration file within your MCP software, save the file, and restart Claude for Desktop (or your specific MCP tool) for the changes to take effect.

Usage

Once the environment is set up and the MCP configuration is applied and the MCP tool is restarted, you should be able to interact with the configured tools (product_data_tools, Bright Data, actors-mcp-server) directly through the interface of your MCP software (e.g., Claude Desktop).

The specific way you "use" each tool depends on its implementation. For product_data_tools, you would typically interact with the API or functionality provided by the server.py file you created.

Visuals / Examples (Placeholder)

An image or screenshot demonstrating how to trigger or interact with the configured tools within the Claude Desktop (or your chosen MCP software) interface would be helpful here.

[Insert URL of relevant image here, or delete this section if no image is provided]

run servers

  uv run server.py
  uv run mcp_data_server.py

This README provides a clear, step-by-step guide for setting up the project and configuring it for use with an MCP tool based on your input. Remember to fill in any placeholders like specific paths or API tokens.

Available Tools

4 tools

get_available_fieldsA

Retrieves the list of available data fields (columns) for filtering and sorting.

Queries the separate Product Data Server.

Args: store_name: Optional. The name of the store to check fields for. If omitted, returns fields available across all stores.

Returns: A dictionary containing a list of available fields (e.g., {'available_fields': [...]}), or a string error message.

ParametersJSON Schema

Name	Required	Description	Default
`store_name`	No

TDQS

A4.4/5.0

Behavior4/5

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

With no annotations, the description carries full burden. It discloses the separate server query and return format (dictionary or error string). Could mention idempotency but adds significant value.

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?

Concise two-sentence description plus structured Args/Returns. Front-loaded with purpose. Every sentence adds value.

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

Completeness5/5

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

Given one optional parameter and no output schema, the description covers purpose, parameter semantics, return format, and server dependency. Complete for a simple retrieval tool.

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

Parameters5/5

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

The single parameter store_name is fully described beyond the schema: optional, meaning, and default behavior. Schema coverage is 0%, so description compensates completely.

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

Purpose5/5

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

The description clearly states it retrieves available data fields for filtering and sorting, and mentions querying a separate server. It distinguishes from sibling tools that deal with products.

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

Usage Guidelines3/5

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

The description explains the store_name parameter behavior but lacks explicit guidance on when to use this tool versus alternatives. No exclusions or prerequisites mentioned.

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

get_overall_top_productsA

Retrieves the top K products across all stores.

Args: k: The number of top products to return. Defaults to 10. Must be a positive integer. sort_by: Optional. The field to sort by (e.g., 'score', 'price'). Defaults to 'score' on the data server. sort_order: Optional. The order of sorting ('asc' or 'desc'). Defaults to 'desc'. fields: Optional. A list of specific fields to include. Defaults to all available fields.

Returns: A list of product dictionaries for the top products, or a string error message.

ParametersJSON Schema

Name	Required	Default
`k`	No
`sort_by`	No
`sort_order`	No	desc
`fields`	No

TDQS

A4/5.0

Behavior3/5

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

No annotations are provided, so the description carries full burden. It discloses that the tool returns a list of dictionaries or an error message, but does not explain how 'top' is determined beyond sort parameters, nor does it mention side effects, rate limits, or error details. Adequate but limited.

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 concise, front-loaded with purpose, and structured with Args and Returns sections. Every sentence adds value, no wasted words.

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

Completeness4/5

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

Given the absence of annotations and output schema, the description covers parameters, return format, and purpose fairly completely. It lacks details on error cases and the exact meaning of 'top' but is adequate for the context.

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

Parameters4/5

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

With 0% schema description coverage, the description adds substantial meaning: clarifies k must be positive integer, sort_by examples (score, price), sort_order options (asc/desc), fields as optional list. This goes beyond the schema's type/defaults, though not exhaustive on valid sort_by values.

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

Purpose5/5

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

The description clearly states the tool retrieves top K products across all stores, using a specific verb and resource. It distinguishes itself from sibling tools like get_product_details_by_url or query_store_products which are not about overall top products.

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

Usage Guidelines3/5

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

The description implies usage when needing top products across all stores but does not explicitly state when to use this over alternatives. No exclusions or comparisons with sibling tools are provided, leaving the agent to infer.

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

get_product_details_by_urlA

Retrieves detailed information for specific products using their URLs.

Queries the separate Product Data Server. Note: The data server expects product_ids, but the client library method takes product_urls. Ensure the data server can correctly map these URLs to its internal product_ids if necessary.

Args: product_urls: A list of product URLs for which to retrieve details. Required. fields: Optional. A list of specific fields to include. Defaults to all available fields.

Returns: A list of product dictionaries for the found products, or a string error message.

ParametersJSON Schema

Name	Required	Description	Default
`product_urls`	Yes
`fields`	No

TDQS

A4.2/5.0

Behavior4/5

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

With no annotations, the description fully carries burden: it explains the separate server query, the mapping requirement, and the return type (list of product dictionaries or error string). It does not mention read-only status or potential side effects.

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?

Description is concise: three sentences plus clear Args/Returns sections, no redundant information, and main purpose is front-loaded.

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

Completeness4/5

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

Covers key aspects: separate server, mapping issue, parameters, return type. Lacks details on error types or structure of returned dictionaries, but overall sufficient for a tool with 2 params and no output schema.

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 description adds minimal value over the schema; it states product_urls is a list of URLs and fields is optional with default all fields. Since schema coverage is 0%, description does compensate but lacks further detail like valid field values or format.

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

Purpose5/5

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

The description clearly states the verb 'retrieves detailed information' and the resource 'specific products using their URLs', distinguishing it from sibling tools like get_available_fields and query_store_products.

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

Usage Guidelines4/5

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

Provides explicit context about the separate Product Data Server and the necessary URL-to-ID mapping, but does not directly compare to alternatives or specify when not to use this tool.

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

query_store_productsA

Retrieves product data from a specific store based on filtering and sorting criteria.

Uses a separate Product Data Server to fetch information.

Args: store_name: The name of the store to search within (e.g., 'aeropress_product_cleaned'). This is required. filter_criteria: Optional. A dictionary specifying filter criteria. Keys are field names (e.g., 'price', 'rating'). Values are either exact match values (e.g., {'rating': 4.5}) or dictionaries for operators (e.g., {'price': {'operator': '<', 'value': 50.0}}). Supported operators by the data server include '==', '!=', '<', '>', '<=', '>='. Consult data server documentation (or the available_fields tool) for available fields and operators. sort_by: Optional. The field name to sort the results by (e.g., 'price', 'rating', 'score'). If not specified, the data server might default to 'score' or its own internal default. sort_order: Optional. The order of sorting ('asc' for ascending, 'desc' for descending). Defaults to 'desc'. limit: Optional. The maximum number of products to return. Defaults to 10. fields: Optional. A list of specific fields to include in the results (e.g., ['product_name', 'price', 'product_url']). If not specified, the data server returns all available fields for the matching products.

Returns: A list of product dictionaries matching the criteria on success. Returns a string error message if the data server cannot be reached, the store is not found, or if there's an error during the query.

ParametersJSON Schema

Name	Required	Default
`store_name`	Yes
`filter_criteria`	No
`sort_by`	No
`sort_order`	No	desc
`limit`	No
`fields`	No

TDQS

A4.2/5.0

Behavior4/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. It discloses behavioral traits such as error conditions (server unreachable, store not found, query error) and defaults (sort_by may default to 'score', limit defaults to 10). This provides good transparency for a read operation.

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

Conciseness4/5

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

The description is moderately long but well-structured with Args and Returns sections. It could be slightly more concise (e.g., 'Optional.' repeats), but every sentence contributes useful information. It is front-loaded with the core action.

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

Completeness4/5

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

Given 6 parameters, one required, no output schema, and sibling tools for additional context, the description covers parameter semantics, default behaviors, and error returns. It could be more specific about output field structure, but the mention of 'product dictionaries' is adequate.

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

Parameters5/5

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

Schema description coverage is 0%, so the description must compensate fully. It does so with an Args section explaining each parameter's purpose, defaults, and value format (e.g., filter_criteria operators, fields list behavior). This adds significant meaning beyond the schema.

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

Purpose5/5

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

The description clearly states the tool retrieves product data from a specific store with filtering and sorting. It distinguishes itself from siblings (store-specific vs. global top products or URL-based details). Verb 'retrieves' and resource 'product data from a specific store' are specific.

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

Usage Guidelines3/5

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

The description does not explicitly state when to use this tool versus alternatives like get_overall_top_products or get_product_details_by_url. Usage is implied through parameter descriptions, but no when-not-to-use guidance is given.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

4 tool updatesv0.1.0May 30, 2026
- First observedget_available_fields
- First observedget_overall_top_products
- First observedget_product_details_by_url
- First observedquery_store_products

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.2/5.0

Disambiguation5/5

Each tool targets a distinct operation: listing available fields, getting top products across stores, retrieving details by URL, and querying a specific store with filters. No overlap in purpose.

Naming Consistency4/5

All tools use snake_case with descriptive names. Three start with 'get_' and one with 'query_', but the pattern is otherwise consistent. The use of 'query' for store-specific search is appropriate.

Tool Count5/5

Four tools are well-suited for a product data retrieval server. They cover the essential read operations without being too few or too many.

Completeness4/5

The tool surface covers key read operations: field discovery, top products, details, and filtered queries. Missing write operations (create/update/delete) are acceptable for a read-focused server, but there is no tool to list available stores, which is a minor gap.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Hotel Rate Monitoring APIOAuth
io.github.veyvey45-eng
Remote MCP server for hotel rate monitoring, parity checks, and pricing intelligence via Apify.
Web Scraping E-commerce & Retail Monitoring
2
Ua E Commerce Price Tracker Mcp
io.github.varvararatta
MCP server for ua_e_commerce_price_tracker_mcp
E-commerce & Retail Web Scraping
2
zenrows-mcp
io.github.ZenRows
Zenrows MCP server — Fetch, Extract, Batch, and Browser Sessions for AI coding assistants
Web Scraping Browser Automation
119
ReefAPI A
io.github.reefapi
One MCP server for 180+ live web-data APIs returning clean JSON from sites that block scrapers.
Web Scraping Browser Automation
523

Related MCP Servers

Scrapezyofficial
RAG Systems Web Scraping
Scrapezy
A
license
C
quality
C
maintenance
MCP Server enabling integration with Scrapezy to retrieve structured data from websites.
Updated a year ago (2025-03-11 08:04 UTC)
1
29
13
MIT
crawl4ai-mcp
Web Scraping Agent Orchestration RAG Systems
ritvij14
F
license
B
quality
D
maintenance
An MCP Server for Web scraping and Crawling, built using Crawl4AI
Updated a year ago (2025-04-14 04:04 UTC)
2
24
-
mcp-server
Browser Automation Web Scraping Developer Tools
FabG
F
license
Not graded
quality
D
maintenance
Provides instructions and code to set up an MCP server using FastMCP, enabling tool creation for LLM interaction, with an example project for extracting product information from Amazon links.
Updated a year ago (2025-05-25 21:52 UTC)
-
web-data-mcp
Web Scraping RAG Systems Browser Automation
fctpe
A
license
A
quality
B
maintenance
An MCP server that runs Apify scraping actors with quality-gated validation, scoring, and retries, returning embedding-ready chunks for AI agents.
Updated 5 days ago (2026-09-01 14:12 UTC)
7
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/ABAKHAR721/data_mcp-server'

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

first install dependencies using uv package

Basic MCP Project Setup

Prerequisites

Installation

1. Install uv

2. Project Setup

Configuration (for Claude Desktop MCP)

Usage

Visuals / Examples (Placeholder)

run servers

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Scrapezyofficial

Latest Blog Posts

MCP directory API

1. Install `uv`