Skip to main content
Glama
JavidGlyv

Turbo.az MCP Server

by JavidGlyv
OverviewSchemaRelated ServersScoreDiscussions
Python
Local

Turbo.az MCP Server

MCP (Model Context Protocol) server for Turbo.az automotive marketplace. This server enables Claude Desktop to search for cars and retrieve listing information from turbo.az.

⚠️ Important Note

Turbo.az blocks access from outside Azerbaijan. This server must run from an Azerbaijani IP:

  • Local computer (in Azerbaijan)

  • Via VPN with Azerbaijan IP

  • From a VPS located in Azerbaijan

Related MCP server: Begagnad MCP

🚀 Installation

1. Requirements

  • Python 3.10+

  • Google Chrome browser

  • pip

2. Server Setup

# Clone the repo or copy files
cd turbo-az-mcp

# Create virtual environment
python -m venv venv

# Activate
# Windows:
venv\Scripts\activate
# Linux/Mac:
source venv/bin/activate

# Install packages
pip install -e .

3. Test

# Run server manually
python -m src.server

4. Test MCP without LLM

Spawns the server and calls tools (requires Chrome):

uv run python scripts/test_mcp.py

🔧 Claude Desktop (local MCP, stdio)

Local-only: Claude Desktop runs the server as a subprocess. Do not use "Add custom connector" / Remote MCP URL.

  1. Find and open the config file:

    • Windows: %APPDATA%\Claude\claude_desktop_config.json

    • macOS: ~/Library/Application Support/Claude/claude_desktop_config.json

    • Linux: ~/.config/Claude/claude_desktop_config.json

  2. Add to mcpServers section (or copy claude_desktop_config.example.json from the project and change cwd to your path):

With uv (recommended):

{
  "mcpServers": {
    "turbo-az": {
      "command": "uv",
      "args": ["run", "python", "-m", "src.server"],
      "cwd": "/home/javid/dev/turbo-mcp"
    }
  }
}

With Python / venv:

{
  "mcpServers": {
    "turbo-az": {
      "command": "python",
      "args": ["-m", "src.server"],
      "cwd": "/home/javid/dev/turbo-mcp"
    }
  }
}

Note: cwd is the full path to the project folder. Restart Claude Desktop.

Claude on Windows, Server in WSL

If Claude Desktop is on Windows but the project is in WSL, use wsl in config. WSL non-interactive shell may not have uv in PATH, so use venv python:

{
  "mcpServers": {
    "turbo-az": {
      "command": "wsl",
      "args": ["bash", "-c", "cd /home/javid/dev/turbo-mcp && .venv/bin/python -m src.server"]
    }
  }
}

Replace /home/javid/dev/turbo-mcp with your WSL project path. If venv is not .venv (e.g. venv), use venv/bin/python instead of .venv/bin/python.

Chrome in WSL: When server runs in WSL, Chrome/Chromium must be installed in WSL for Selenium (Windows Chrome won't work). In WSL terminal:

sudo apt update && sudo apt install -y chromium-browser

If chromium-browser requires snap, install Google Chrome for Linux or set CHROME_BINARY=/usr/bin/chromium (or installed path).

📋 Available Tools

1. search_cars

Search for cars.

Parameters:

  • make - Brand (BMW, Mercedes, Toyota, etc.)

  • model - Model (X5, E-Class, etc.)

  • price_min / price_max - Price range (AZN)

  • year_min / year_max - Year range

  • fuel_type - Fuel: benzin, dizel, qaz, elektrik, hibrid

  • transmission - avtomat, mexaniki

  • limit - Number of results (default: 10)

Example query: "Search for BMW X5 from 2020, price up to 50000 AZN on Turbo.az"

2. get_car_details

Detailed listing information.

Parameters:

  • listing_id - Listing ID or full URL

Example query: "Show details of this listing on Turbo.az: 12345678"

3. get_makes_models

List of makes and models.

Parameters:

  • make - Brand (to see its models, empty = all makes)

Example query: "What BMW models are available on turbo.az?"

4. get_trending

New/popular listings.

Parameters:

  • category - new, popular, vip

  • limit - Number of results

🐛 Troubleshooting

"403 Forbidden" error

  • Make sure you're running from Azerbaijan IP

  • Use VPN (Azerbaijan IP)

ChromeDriver error

  • Make sure Chrome browser is installed

  • webdriver-manager automatically downloads ChromeDriver

"DevToolsActivePort file doesn't exist" (WSL)

  • chromium-browser (snap) often doesn't work in WSL. Install Google Chrome:

    wget -q https://dl.google.com/linux/direct/google-chrome-stable_current_amd64.deb
sudo dpkg -i google-chrome-stable_current_amd64.deb
sudo apt install -f

  • Or with virtual display: sudo apt install xvfb then xvfb-run -a uv run python scripts/test_mcp.py

Timeout error

  • Check internet connection

  • Check if turbo.az is working

📄 License

MIT

Available Tools

4 tools
get_car_detailsC

Fetches detailed listing info from Turbo.az. Requires listing ID or URL.

ParametersJSON Schema
NameRequiredDescriptionDefault
listing_idYesListing ID (e.g. 1234567) or full URL

TDQS

C2.9/5.0
Behavior2/5

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 mentions the requirement for a listing ID or URL but doesn't cover other behavioral aspects such as rate limits, authentication needs, error handling, or what 'detailed listing info' includes. This leaves significant gaps for a tool that fetches data.

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 concise and front-loaded with the main action and requirement in a single sentence. There's no wasted text, making it efficient, though it could benefit from slightly more detail to improve completeness without sacrificing brevity.

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 'detailed listing info' entails, potential response formats, or error cases. For a data-fetching tool with no structured output documentation, this leaves the agent with insufficient context to use the tool effectively.

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 beyond the input schema, which has 100% coverage and clearly documents the 'listing_id' parameter. It clarifies that the parameter can be an ID or URL, but this is already implied by the schema's description. With high schema coverage, the 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.

Purpose4/5

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

The description clearly states the action ('fetches detailed listing info') and resource ('from Turbo.az'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'search_cars' or 'get_trending' beyond mentioning it's for 'detailed listing info' rather than search or trending data.

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 minimal guidance by stating it 'requires listing ID or URL', but offers no explicit advice on when to use this tool versus alternatives like 'search_cars' or 'get_trending'. It lacks context on prerequisites or scenarios where this tool is preferred.

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

get_makes_modelsB

Fetches list of available makes and models on Turbo.az.

ParametersJSON Schema
NameRequiredDescriptionDefault
makeNoMake name (to see its models). Leave empty for all makes.

TDQS

B3.1/5.0
Behavior2/5

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 it 'fetches list', implying a read-only operation, but doesn't address key aspects like authentication needs, rate limits, pagination, or error handling. For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.

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 purpose without unnecessary words. It's appropriately sized and front-loaded, with zero waste, making it easy to parse 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 low complexity (one optional parameter, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose but lacks details on usage, behavior, and output format, which could be important for an agent to use it effectively. It meets the minimum threshold but has clear gaps.

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 doesn't mention the 'make' parameter or add any semantic context beyond what's in the input schema, which has 100% coverage. The schema already describes the parameter as 'Make name (to see its models). Leave empty for all makes.', so the description provides no additional value. Baseline is 3 when schema coverage is high.

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 action ('fetches list') and resource ('available makes and models on Turbo.az'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'search_cars' or 'get_car_details', which might also involve makes/models in some capacity, so it doesn't reach the highest level of specificity.

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 like 'search_cars' or 'get_trending'. It lacks context about use cases, prerequisites, or exclusions, leaving the agent to infer usage based on the tool name alone.

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

search_carsC

Car search on Turbo.az. Search by make, model, price range, year, etc.

ParametersJSON Schema
NameRequiredDescriptionDefault
makeNoCar make (e.g. BMW, Mercedes, Toyota)
modelNoCar model (e.g. X5, E-Class, Camry)
price_minNoMinimum price (AZN)
price_maxNoMaximum price (AZN)
year_minNoMinimum year of manufacture
year_maxNoMaximum year of manufacture
fuel_typeNoFuel type: petrol, diesel, gas, electric, hybrid
transmissionNoTransmission: automatic, manual
limitNoResult count limit (default: 20)

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations provided, the description carries full burden but lacks behavioral details. It doesn't disclose whether this is a read-only operation, if it requires authentication, rate limits, pagination behavior (beyond the 'limit' param), or what the output format looks like (e.g., list of cars with basic info). For a search tool with 9 parameters, 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.

Conciseness4/5

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

The description is a single, efficient sentence that front-loads the core purpose. It avoids redundancy and wastes no words, though it could be slightly more structured by explicitly mentioning the platform ('Turbo.az') earlier.

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 complexity (9 parameters, no annotations, no output schema), the description is incomplete. It doesn't explain the return values, error conditions, or behavioral traits needed for effective use. For a search tool, this leaves significant gaps in understanding how results are formatted or limited.

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 100%, so the schema fully documents all 9 parameters with descriptions and defaults. The description adds minimal value by listing example criteria ('make, model, price range, year, etc.') but doesn't provide additional semantics beyond what's in the schema, such as how parameters interact or search logic.

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 action ('search') and resource ('cars on Turbo.az'), specifying it's a search operation with example criteria. It distinguishes from sibling tools like 'get_car_details' (detail retrieval) and 'get_makes_models' (metadata), though not explicitly. However, it doesn't fully differentiate from potential 'get_trending' if that also returns cars.

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 like 'get_car_details' or 'get_makes_models'. It mentions search criteria but doesn't specify prerequisites, exclusions, or contextual triggers for choosing this over siblings, leaving the agent to infer usage.

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

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

TDQS

B3.4/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose with no ambiguity: get_car_details retrieves specific listing details, get_makes_models provides metadata, get_trending shows popular listings, and search_cars enables filtered searches. The descriptions clearly differentiate their functions, making misselection unlikely.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern with snake_case naming (get_car_details, get_makes_models, get_trending, search_cars). The verbs 'get' and 'search' are appropriately used and maintain a predictable structure throughout the set.

Tool Count4/5

With 4 tools, the server is well-scoped for a car listing domain, covering key operations like searching, viewing details, browsing trends, and accessing metadata. It feels slightly thin but reasonable, as each tool earns its place without redundancy.

Completeness4/5

The toolset covers core read-only operations for a car listing service: search, detail viewing, trend access, and metadata retrieval. Minor gaps exist, such as no tools for user interactions (e.g., saving favorites or contacting sellers), but agents can perform essential browsing tasks effectively.

Maintenance

ActivityInactive
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

Related MCP Servers

  • Data Engineer Agent

    abbasnosrat
    F
    license
    Not graded
    quality
    D
    maintenance
    Enables AI agents to interact with a retail cars database using SQL queries. Supports adding new car advertisements and searching existing cars based on user preferences through natural language.

  • Begagnad MCP

    bjesus
    F
    license
    Not graded
    quality
    F
    maintenance
    Enables AI agents to search and retrieve listings from Sweden's largest second-hand marketplaces, Blocket and Tradera. Returns unified data including prices, images, seller information, and direct links to listings.
    8

  • MarketCheck MCP Apps

    MarketcheckHub
    F
    license
    Not graded
    quality
    B
    maintenance
    Provides 25 interactive automotive intelligence tools for real-time market data, including VIN decoding, price predictions, and inventory analytics. It enables AI assistants to perform car searches, trade-in estimations, and market trend analysis using the Model Context Protocol.
    2

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/JavidGlyv/Turboaz-MCP'

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