originselect

Name: originselect
Author: chhavimishra

by chhavimishra

Overview Schema Related Servers Score Discussions

JavaScript

Remote

OriginSelect MCP Server

npm version License: MIT

Model Context Protocol server for OriginSelect — search ethical, origin-verified products and brands via AI agents.

Works with Claude Desktop, Cursor, Windsurf, and any MCP-compatible client.

Quick Start

Option 1: npx (recommended)

No install needed — just add to your Claude Desktop config:

{
  "mcpServers": {
    "originselect": {
      "command": "npx",
      "args": ["originselect-mcp-server"]
    }
  }
}

Option 2: Global install

npm install -g originselect-mcp-server

Then add to Claude Desktop config:

{
  "mcpServers": {
    "originselect": {
      "command": "originselect-mcp-server"
    }
  }
}

Option 3: From source

git clone https://github.com/chhavimishra/originselect-mcp-server.git
cd originselect-mcp-server
npm install

{
  "mcpServers": {
    "originselect": {
      "command": "node",
      "args": ["/absolute/path/to/originselect-mcp-server/src/index.js"],
      "env": {
        "API_BASE_URL": "https://api.originselect.com"
      }
    }
  }
}

Cursor / Windsurf

Add to your MCP settings:

{
  "originselect": {
    "command": "npx",
    "args": ["originselect-mcp-server"]
  }
}

Related MCP server: BuyWhere Catalog MCP Server

Example Queries

Once connected, ask your AI assistant:

"Find organic baby products from Canada under $25"
"Show me women-owned coffee brands in the US"
"What B Corp certified skincare brands do you have?"
"Find vegan, cruelty-free pet products"

Tools

`search_products`

Search the curated product catalog by values, country, category, brand, or keywords.

"Find organic baby products from Canada under $25"
→ { country: "Canada", category: "Baby", values: ["organic"], priceMax: 25 }

Parameter	Type	Description
`query`	string	Optional NL query for context
`country`	string	Country of origin (Canada, USA)
`category`	string	Product category (Beauty, Baby, Pet Care, etc.)
`values`	string[]	Ethical values (women-owned, organic, b-corp, etc.)
`brand`	string	Brand name
`keywords`	string[]	Product keywords (shampoo, coffee, etc.)
`priceMax`	number	Maximum price in dollars
`market`	string	`canada`, `global`, or `all` (default: all)
`limit`	number	Max products (1-50, default: 12)

`search_brands`

Discover brands by ethical values, country, or category.

Parameter	Type	Description
`country`	string	Country of origin
`values`	string[]	Ethical values
`category`	string	Product category
`brand`	string	Brand name to look up
`market`	string	Market scope
`limit`	number	Max brands (1-20, default: 10)

`refine_search`

Refine a previous search by adding/removing filters. Takes the intent object from a prior search_products response and applies modifications — no need to re-query from scratch.

{
  "intent": { "...from previous response..." },
  "modifications": [
    { "action": "add", "field": "values", "value": "organic" },
    { "action": "remove", "field": "values", "value": "vegan" },
    { "action": "modify", "field": "priceMax", "value": 30 }
  ]
}

`get_values`

List all 21 supported ethical/ownership values (women-owned, b-corp, organic, etc.).

`get_categories`

List all 17 supported product categories.

`get_countries`

List all supported countries of origin (currently Canada and USA).

Architecture

AI Agent (Claude, GPT, Cursor)
    │
    │  MCP (stdio)
    ▼
┌─────────────────────────┐
│  MCP Server (this pkg)  │
│  6 tools                │
└───────────┬─────────────┘
            │  HTTPS
            ▼
┌─────────────────────────┐
│  OriginSelect API       │
│  api.originselect.com   │
└─────────────────────────┘

Environment Variables

Variable	Default	Description
`API_BASE_URL`	`https://api.originselect.com`	Discovery API base URL

Supported Values

women-owned · black-owned · indigenous-owned · veteran-owned
family-owned · lgbtq-owned · aapi-owned · latino-owned · minority-owned
b-corp · organic · sustainable · vegan · non-gmo · fair-trade
non-toxic · cruelty-free · fragrance-free · plastic-free
social-impact · gluten-free

Security & Trust

This MCP server is open source and fully auditable:

Read-only — only makes outbound HTTPS requests to api.originselect.com
No filesystem access — does not read or write any local files
No telemetry — does not send user data or analytics anywhere
Minimal dependencies — single runtime dependency (@modelcontextprotocol/sdk)
Source code — github.com/chhavimishra/originselect-mcp-server

See SECURITY.md for vulnerability reporting.

License

MIT

Available Tools

6 tools

get_categoriesB

List all supported product categories that can be used to filter products and brands.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.4/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 behavioral burden but offers minimal disclosure beyond 'List all.' It does not clarify return format (IDs vs names vs objects), list size/volume, caching, or rate limits. The word 'supported' implies a fixed enum set, but this is thin 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.

Conciseness5/5

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

Single sentence, front-loaded with the action verb, zero redundancy. Every word earns its place in explaining scope and utility.

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 simple lookup tool with no parameters, the description is minimally adequate. However, the absence of an output schema means the description should ideally describe the return structure (e.g., 'returns list of category objects with id and name'), which is missing.

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 input schema has zero parameters. Per scoring rules, 0 parameters establishes a baseline score of 4. The description correctly implies no filtering arguments are needed by stating 'List all.'

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 specific verb ('List') and resource ('product categories') with clear scope ('all supported'). It implicitly distinguishes from sibling search tools by positioning the output as filter values for 'products and brands,' though it does not explicitly contrast with get_countries.

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?

It provides implied context by stating categories 'can be used to filter products and brands,' hinting at the workflow (use before searching). However, it lacks explicit when-to-use/when-not-to-use guidance or direct references to sibling tools like search_products.

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

get_countriesA

List all supported countries of origin that can be used to filter products and brands. Currently supports Canada and USA.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4/5.0

Behavior3/5

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

No annotations provided, so description carries full burden. It adds valuable behavioral context by disclosing the limited dataset ('Currently supports Canada and USA'). However, it omits other behavioral traits like caching, return format structure, or whether results are static/dynamic.

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?

Two sentences with zero waste: first establishes purpose and usage context, second provides current limitations. Information is front-loaded and appropriately sized for a simple enumeration tool.

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?

For a zero-parameter lookup tool, the description adequately covers purpose and data constraints. Minor gap: does not specify return format (e.g., ISO codes vs full names) despite lack of output schema, though 'Canada and USA' provides a reasonable hint.

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?

Input schema contains zero parameters, establishing a baseline of 4. The description appropriately does not mention parameters since none exist, maintaining the baseline without adding or subtracting value.

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 uses specific verb 'List' with resource 'countries of origin' and explicitly distinguishes from sibling get_categories by specifying the domain (countries vs categories). The scope is further clarified by 'Currently supports Canada and USA'.

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?

Provides implied usage context by stating countries 'can be used to filter products and brands,' which hints at using this before search_products/search_brands. However, lacks explicit when-to-use vs when-not-to-use guidance or direct comparison to sibling tools like get_categories.

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

get_valuesA

List all supported ethical/ownership values that can be used to filter products and brands. Returns canonical value tokens with display labels.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4/5.0

Behavior3/5

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

No annotations provided, so description carries full burden. It discloses return structure ('canonical value tokens with display labels') which compensates for missing output_schema, but omits other behavioral traits like caching, pagination, or rate limiting.

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?

Two efficient sentences with zero waste: first establishes purpose, second explains return format. Perfectly front-loaded with no redundancy.

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 no output schema exists, the description adequately explains return values ('canonical value tokens with display labels'). Covers essential context for a simple enumeration tool, though explicit mention of relationship to search_products could strengthen completeness.

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?

Input schema has 0 parameters, establishing baseline 4 per scoring rules. Description appropriately requires no additional parameter explanation since the tool takes no arguments.

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 uses specific verb 'List' with clear resource 'ethical/ownership values' and distinguishes from siblings (get_categories, get_countries) by specifying the exact domain of values returned.

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?

Provides implied usage context ('can be used to filter products and brands') suggesting when these values are relevant, but lacks explicit guidance on when to call this versus siblings or prerequisites for search operations.

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

refine_searchA

Refine a previous product search by adding/removing filters. Takes the intent object from a prior search_products response and applies modifications. No new query parsing needed — this is a fast refinement.

Examples:

Add a value: { action: "add", field: "values", value: "organic" }
Remove a value: { action: "remove", field: "values", value: "vegan" }
Change country: { action: "modify", field: "country", value: "Canada" }
Set max price: { action: "modify", field: "priceMax", value: 30 }
Change category: { action: "modify", field: "category", value: "Beauty" }

ParametersJSON Schema

Name	Required	Description
`intent`	Yes	The intent object returned from a previous search_products call. Pass it unchanged.
`modifications`	Yes	Array of modifications to apply to the intent
`market`	No	Market scope override
`limit`	No	Max products to return (1-50)

TDQS

A4.2/5.0

Behavior3/5

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

With no annotations provided, the description carries the full burden. It adds valuable behavioral context ('fast refinement', 'no new query parsing needed') but omits safety profile (read-only vs. destructive), error handling for invalid intent objects, or idempotency guarantees.

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?

Every sentence earns its place: purpose statement, input requirement, performance characteristic, then actionable examples. No redundancy. The examples are formatted efficiently and demonstrate the parameter patterns clearly.

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 tool's workflow complexity (dependency on prior search_products call, nested modification objects), the description adequately covers the main usage pattern and prerequisites. No output schema exists to describe. Minor gap in not addressing error states or invalid modification scenarios.

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?

Schema coverage is 100%, establishing a baseline of 3. The description adds significant value through concrete examples showing valid action/field/value combinations (e.g., 'modify' with priceMax vs. 'add' with values), clarifying the semantics of how modifications apply beyond the raw schema definitions.

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?

Specific verb ('Refine') + resource ('product search') with clear scope (adding/removing filters). Explicitly distinguishes from sibling 'search_products' by stating it takes 'the intent object from a prior search_products response' and requires 'no new query parsing'.

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 clear context on when to use (requires prior search_products response) and implies when not to use ('no new query parsing needed'). However, it does not explicitly state the alternative tool name for new searches, only implying it by referencing search_products as the source of the intent object.

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

search_brandsA

Search for ethical and origin-verified brands on OriginSelect. Filter by country of origin, ethical values (women-owned, b-corp, organic, etc.), and product category. Returns brand details including values, website, and product count.

ParametersJSON Schema

Name	Required	Description	Default
`country`	No	Country of origin to filter by
`values`	No	Ethical/ownership values to filter by
`category`	No	Product category the brand operates in
`brand`	No	Brand name to look up directly
`market`	No	Market scope	all
`limit`	No	Maximum number of brands to return (1-20)

TDQS

A4/5.0

Behavior4/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 successfully discloses return values ('brand details including values, website, and product count') compensating for the missing output schema, though it omits safety permissions or error handling specifics.

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?

Three well-structured sentences: purpose declaration, filtering capabilities, and return value disclosure. No redundant or filler text. Information is front-loaded with the core action in the first sentence.

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 rich input schema (100% coverage, 3 enum fields) and lack of output schema, the description appropriately focuses on explaining the return structure and primary use case. It adequately covers the tool's functionality without needing to document individual parameters that are well-schematized.

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?

Input schema has 100% description coverage, establishing a baseline of 3. The description mentions filter categories (country, values, category) but primarily repeats enum examples already present in the schema without adding syntax guidance, validation rules, or semantic relationships between parameters.

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?

Description clearly states the specific action (search), resource (ethical and origin-verified brands), and platform (OriginSelect). It distinguishes from sibling 'search_products' by focusing on brands rather than individual 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 through filter examples (country, values, category) but provides no explicit when-to-use guidance versus siblings like 'refine_search' or 'get_categories/get_values' discovery tools. No prerequisites or exclusions are mentioned.

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

search_productsA

Search OriginSelect's curated catalog of ethical, origin-verified products. Filter by country of origin, ethical values (e.g., women-owned, organic, b-corp), product category, brand, and price. Returns scored and ranked results with match reasons.

ParametersJSON Schema

Name	Required	Description	Default
`query`	No	Optional natural language query for context (e.g., "non-toxic baby shampoo from Canada"). Structured fields below take precedence.
`country`	No	Country of origin to filter by
`category`	No	Product category
`values`	No	Ethical/ownership values to filter by (e.g., ["women-owned", "organic", "non-toxic"])
`brand`	No	Brand name to search for
`keywords`	No	Specific product keywords (e.g., ["shampoo", "moisturizer"])
`priceMax`	No	Maximum price in dollars
`classification`	No	Canadian brand classification filter
`market`	No	Market scope: "canada" for Canadian products only, "global" for international, "all" for both	all
`limit`	No	Maximum number of products to return (1-50)

TDQS

A3.8/5.0

Behavior3/5

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

With no annotations provided, the description carries the full burden. It successfully discloses return behavior ('scored and ranked results with match reasons') but omits operational traits like read-only safety, rate limits, pagination behavior, or error conditions. Partial compensation for missing annotations.

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?

Three sentences with zero waste: first establishes purpose, second lists filtering capabilities, third describes return format. Front-loaded with the core action ('Search OriginSelect's curated catalog') and appropriately sized for the parameter complexity.

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 10 parameters with 100% schema coverage and no output schema, the description adequately compensates by explaining the return format ('scored and ranked results with match reasons'). Complete for a search tool of this complexity, though could explicitly note that all filters are optional.

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%, establishing a baseline of 3. The description lists filterable fields (country, values, category, brand, price) matching schema parameters, and provides examples like 'women-owned, organic, b-corp' that mirror schema enums. Does not add significant semantic meaning beyond the comprehensive schema definitions.

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?

Description explicitly states the tool searches 'OriginSelect's curated catalog of ethical, origin-verified products' with specific verb and resource. It clearly distinguishes from sibling tools like 'search_brands' (products vs brands) and 'get_categories'/'get_countries' (search vs metadata retrieval).

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?

Provides implicit usage guidance by listing filterable dimensions (country, values, category, brand, price) and noting that results are 'scored and ranked with match reasons.' However, lacks explicit guidance on when to use versus siblings like 'refine_search' or 'search_brands,' and doesn't mention that all parameters are optional.

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.

6 tool updatesv1.0.9Apr 4, 2026
- First observedget_categories
- First observedget_countries
- First observedget_values
- First observedrefine_search
- First observedsearch_brands
- First observedsearch_products

Install Server

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

TDQS

A4/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: three metadata enumerators (categories/countries/values), two distinct search targets (brands vs products), and one refinement operation. No functional overlap exists between any pair.

Naming Consistency5/5

Perfectly consistent snake_case convention with clear verb_noun structure throughout: 'get_' prefix for metadata retrieval, 'search_' prefix for discovery operations, and 'refine_search' for the modification action.

Tool Count5/5

Six tools is ideal for this focused search/discovery domain. The surface covers metadata discovery, primary search vectors (brands and products), and result refinement without bloat or missing core capabilities.

Completeness4/5

Strong coverage for a read-only search API: filtering dimensions are fully exposed via metadata endpoints, and both major entity types (brands/products) are searchable. Minor gap: refine_search appears product-specific with no equivalent brand refinement, and lacks single-item retrieval by ID (though search may suffice).

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

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

Lowvyn A
com.lowvyn
Verify Canadian deals, find the same product cheaper across .ca retailers, track CAD price history.
E-commerce & Retail Search
82
UNITEMFG U.S. Manufacturer Directory
com.unitemfg
Search verified U.S. manufacturers with provenance, freshness, and live directory statistics.
Search Open Data Research & Data
1
charity-registry A
com.giveradar
Search, verify and compare 7.9M+ nonprofits from official charity registries in 100+ countries.
Government Data Open Data
2
BeauticsLabOAuth
com.beauticslab
Search Korean cosmetics from Olive Young, Daiso, Naver, Coupang, 11st with EWG ingredient analysis.
E-commerce & Retail Health & Wellness
2

Related MCP Servers

URDB MCP
Search Research & Data E-commerce & Retail
GetMystAdmin
A
license
A
quality
C
maintenance
Search URDB's product integrity database — integrity scores, enshittification events, warranty cuts, and material downgrades across consumer products. Sourced and evidence-backed.
Updated a month ago (2026-08-07 00:22 UTC)
4
70
2
MIT
BuyWhere Catalog MCP Serverofficial
E-commerce & Retail Search
BuyWhere
A
license
A
quality
A
maintenance
Cross-border product catalog for AI agents. Search and compare products from US and South East Asian markets via Model Context Protocol.
Updated 2 days ago (2026-09-04 12:24 UTC)
6
524
10
MIT
ShopSignal
E-commerce & Retail Search
codesk90
F
license
Not graded
quality
D
maintenance
DTC competitor intelligence: catalog snapshots, price history, cross-brand product comparison, and drop/restock detection for 84 Shopify-powered brands. Pay-per-call via Apify.
Updated 3 months ago (2026-05-22 22:28 UTC)
-
fylings-mcp
Government Data Open Data Search
HeyZod
A
license
Not graded
quality
C
maintenance
Search, verify and screen over 1 million African companies across 18 official government registries, along with the public contracts they have won and OFAC/UN sanctions screening. Every result carries its registry source, date and a confidence signal, and the server returns nulls rather than fabricating data.
Updated a month ago (2026-07-27 02:45 UTC)
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/chhavimishra/originselect-mcp-server'

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

OriginSelect MCP Server

Quick Start

Option 1: npx (recommended)

Option 2: Global install

Option 3: From source

Cursor / Windsurf

Example Queries

Tools

search_products

search_brands

refine_search

get_values

get_categories

get_countries

Architecture

Environment Variables

Supported Values

Security & Trust

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

BuyWhere Catalog MCP Serverofficial

Latest Blog Posts

MCP directory API

`search_products`

`search_brands`

`refine_search`

`get_values`

`get_categories`

`get_countries`