Skip to main content
Glama
Automate-with-Sanjay

olx-india-mcp

by Automate-with-Sanjay
OverviewSchemaRelated ServersScoreDiscussions
JavaScript

OLX India MCP Server

An MCP (Model Context Protocol) server designed to searchclassified product listings and retrieve detailed specifications, images, and seller profiles from OLX India (olx.in).

This server allows AI assistants (like Claude, Cursor, etc.) to fetch real-time listings for cars, properties, mobiles, electronics, jobs, and services directly from OLX India.

Features

  • Search Listings: Find classified ads on OLX India with options to filter by query keywords, common Indian cities (Delhi, Mumbai, Bangalore, Pune, etc.), min/max price, sorting, and pagination.

  • Detailed Retrieval: Extract full item specifications, seller info, posting date, specifications/parameters (e.g. brand, model, KM driven, fuel type), description, and image gallery.

  • Robust Scraping: Employs curl-based request patterns to bypass JA3 TLS handshake blocks and load full page state objects.

Related MCP server: marktplaats-mcp

Tools

1. search_listings

Search for classified listings on OLX India.

Input Arguments:

  • query (string, required): The product keywords to search for (e.g. "iphone 15 pro", "honda city").

  • location (string, optional): Target city or state. Supports common terms: "delhi", "mumbai", "bangalore", "hyderabad", "chennai", "kolkata", "pune", etc.

  • min_price (number, optional): Minimum price filter in INR.

  • max_price (number, optional): Maximum price filter in INR.

  • sort_by (string, optional): Sort sorting. Enum: price-asc, price-desc, newest, relevance.

  • page (number, optional): Page number to retrieve (starts at 1).

2. get_listing_details

Retrieve comprehensive details for a specific listing using its URL or ID.

Input Arguments:

  • url_or_id (string, required): The full OLX listing URL or the numeric listing ID.

Configuration & Usage

1. Using with Claude Desktop

Add the server to your Claude Desktop configuration file.

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

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

Add the following under the mcpServers section:

Option A: Running via npm (npx)

This is the recommended approach for quick execution.

{
  "mcpServers": {
    "olx-india-mcp": {
      "command": "npx",
      "args": [
        "-y",
        "olx-india-mcp"
      ]
    }
  }
}

Option B: Running from local cloned path

Use this if you have cloned the source code locally.

{
  "mcpServers": {
    "olx-india-mcp": {
      "command": "node",
      "args": [
        "C:/path/to/olx-india-mcp/dist/index.js"
      ]
    }
  }
}

(Make sure to use forward slashes / in paths on Windows in your JSON file).

2. Using with Cursor

To configure with Cursor:

  1. Open Cursor Settings -> Features -> MCP.

  2. Click + Add New MCP Server.

  3. Name it olx-india-mcp.

  4. Set the Type to command.

  5. Enter the Command: npx -y olx-india-mcp (or node C:/path/to/olx-india-mcp/dist/index.js for local built path).

Local Development

Prerequisites

  • Node.js (v18 or higher recommended)

  • curl installed on your system (native on Windows 10/11, macOS, and most Linux distros)

Setup & Build

  1. Clone the repository.

  2. Install dependencies:

    npm install

  3. Build the TypeScript source code:

    npm run build

  4. Run locally (using stdio):

    npm start

License

This project is licensed under the MIT License - see the LICENSE file for details.

Available Tools

2 tools
get_listing_detailsA

Retrieve comprehensive details, description, full attributes, images, and seller profile for a specific OLX listing using its URL or Listing ID.

ParametersJSON Schema
NameRequiredDescriptionDefault
url_or_idYesThe full OLX listing URL or the numeric Listing ID.

TDQS

A3.5/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 the behavioral burden. It clearly indicates a read-only retrieval operation ('Retrieve'). However, it does not disclose whether the tool requires any specific access, what happens with invalid or non-existent URLs/IDs, rate limits, or the exact shape of the returned data. The read-only nature is implied but return format is undocumented.

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, front-loaded with the verb 'Retrieve' and the object. There is minor redundancy ('full attributes, images, and seller profile' alongside 'comprehensive details') but overall it is tight and organized.

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?

The description adequately conveys the tool's scope for a simple single-parameter retrieval tool with 100% schema coverage. However, with no output schema and no annotations, it would benefit from describing what the return data looks like and behavior around missing/invalid inputs to be fully complete. The multi-item list of returned content mitigates but does not fully close this gap.

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?

The schema already describes the single parameter ('full OLX listing URL or numeric Listing ID') with 100% coverage. The description adds clarity by emphasizing the two accepted input forms (URL or ID). This meaningfully supplements the schema by confirming either format works, which is helpful operational information.

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 uses a clear verb-resource structure ('Retrieve comprehensive details... for a specific OLX listing') and specifies the two input forms (URL or Listing ID). It distinguishes from the sibling 'search_listings' tool, though it does not explicitly state the differentiation. Slightly verbose with redundant qualifiers like 'comprehensive details, description, full attributes...'.

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 for fetching individual listing details rather than searching, but does not explicitly state when to use this vs search_listings, nor provide exclusion criteria or prerequisites. Usage is inferable from the sibling context but not directly articulated.

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

search_listingsB

Search for classified product listings on OLX India with optional location, pricing, sorting, and page parameters.

ParametersJSON Schema
NameRequiredDescriptionDefault
pageNoOptional page number to retrieve (starts at 1).
queryYesThe product keywords to search for (e.g. 'iphone 15 pro', 'honda city').
sort_byNoOptional sorting of results (default is relevance/default sorting).
locationNoOptional city/state location. Common values: 'delhi', 'mumbai', 'bangalore', 'chennai', 'hyderabad', 'kolkata', 'pune', etc.
max_priceNoOptional maximum price filter in INR.
min_priceNoOptional minimum price filter in INR.

TDQS

B3.2/5.0
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 behavioral burden. The description doesn't disclose pagination limits, result counts returned, rate limits, whether location matching is fuzzy, or how sorting interacts with relevance. For a search tool, behavior around defaults and result set breadth would be valuable context.

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 focused sentence that lists the key optional dimensions (location, pricing, sorting, page). It's concise and front-loaded with the core purpose. Could mention a typical example but isn't padded with filler.

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?

For a search tool with one required param and no output schema, the description is adequate but could be more complete. There's no mention of result count limits, whether the location parameter supports abbreviations, or guidance on combining filters. The tool is moderately complex (6 optional params) but the schema covers their individual semantics well enough.

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 documents all 6 parameters well. The description adds the default sorting behavior (relevance/default) which is a marginal bonus, but otherwise the parameters are fully self-documenting in the schema. Baseline 3 is appropriate.

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 verb (search), resource (classified product listings on OLX India), and scope (with location, pricing, sorting, and page parameters). It distinguishes from the sibling tool 'get_listing_details' by the search-action vs. detail-retrieval, though it doesn't explicitly name the alternative.

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?

Usage is implied by the purpose - searching for listings - and the optional parameters describe typical use cases. However, there's no explicit guidance on when to use this tool vs. get_listing_details (e.g., 'use this to discover listings, then get_listing_details for a specific one'). No exclusions or prerequisites are mentioned.

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.

  1. 2 tool updatesv1.0.0
    • First observedget_listing_details
    • First observedsearch_listings
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.3/5.0
Disambiguation5/5

The two tools serve clearly distinct purposes: one searches for listings with filters, the other retrieves detailed information about a specific listing. There is no ambiguity about which tool handles which task.

Naming Consistency4/5

Both tools follow a consistent noun-phrase pattern with descriptive names (search_listings, get_listing_details). The pattern is logical and predictable, though a more uniform verb_noun structure could make it even more consistent.

Tool Count2/5

With only 2 tools, the server feels extremely thin for a classifieds platform. A typical OLX workflow would require at least a handful more tools (e.g., filtering by category, browsing subcategories, location listing). Two tools is borderline under-minimal for the apparent scope.

Completeness2/5

The server covers search and detail retrieval, but lacks common operations expected from a classifieds platform such as browsing by category, managing saved/favorite listings, or posting listings. While search+detail is the read path, there are notable gaps in category discovery and navigation.

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

  • marktplaats-mcp

    PonClick
    A
    license
    Not graded
    quality
    F
    maintenance
    Enables AI assistants to search and view advertisements on Marktplaats.nl with extensive filtering options.
    16
    MIT

  • marktplaats-mcp

    jasp-nerd
    A
    license
    A
    quality
    A
    maintenance
    Enables AI agents to search and monitor Dutch and Belgian classifieds (Marktplaats and 2dehands) for listings, seller profiles, and categories.
    5
    2
    MIT

  • olx-mcp

    tkupcewicz
    A
    license
    Not graded
    quality
    D
    maintenance
    MCP server for OLX marketplace. Enables AI assistants to search listings, get offer details, track prices over time, and compare offers across OLX Poland and other supported countries.
    622
    4
    MIT

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/Automate-with-Sanjay/OLX_INDIA_MCP_SERVER'

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