Partle
REMOTE · PARTLE.RUBENAYLA.XYZ · SCANNED SEP 20
Search products in nearby stores. Agents can also list items for sale on a user's behalf.
Available components
Recent critical change
Authorization (6 Aug 2026). See the changelog before you install this server.
How this component scores in each security and reliability category. Every signal is checked automatically against the live server, and we only credit what we can confirm. How we score → Why this is hard to score →
Endpoint Security57
- The endpoint's TLS certificate is valid, in date, and uses a strong key. View diagnostics → Pass
- Authorisation check failed: no authorisation is required to call this server, and it exposes a tool marked destructive (delete_product). See how to fix → View diagnostics → Fail
- HTTPS is enforced; there's no plaintext access path. View diagnostics → Pass
- HSTS check failed: the Strict-Transport-Security header is absent. See how to fix → View diagnostics → Fail
- DNSSEC check failed: this domain isn't protected by DNSSEC. See how to fix → View diagnostics → Fail
Transport & Reachability100
- Verified streamable-http transport via a live MCP handshake. View diagnostics → Pass
Schema Quality & AI Usability62
- AI-judged instruction clarity (excellent).Pass
- Context-footprint check failed: tool/resource definitions use about 8550 tokens (~407/item across 21 items; 21 tools + 0 resources), over budget; trim descriptions and params. See how to fix → Fail
- Usage-examples check failed: none of the tools include examples. See how to fix → Fail
Stability & Change Management100
- No destabilizing schema changes in the last 30 days.Pass
Tool Coverage71
- 100% of tools have a non-trivial description (not blank, and not just the tool's name).Pass
- 0% of tool parameters carry a description.Fail
- Structured output schemas are declared (19% of tools); any adoption earns full credit.Pass
Tool Safety100
- No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.Pass
- All 3 tool(s) whose name or description implies an irreversible operation declare an MCP destructiveHint annotation.Pass
- An AI judge read all 22 captured unit(s) of tool text and found none that tries to manipulate the model reading it.Pass
Capabilities100
- Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.Pass
How do I install the Partle MCP server?
Partle is a hosted endpoint at https://partle.rubenayla.xyz/mcp/, so there is nothing to install locally. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.
remote · partle.rubenayla.xyz
claude mcp add --transport http xyz-rubenayla-partle-marketplace 'https://partle.rubenayla.xyz/mcp/'
{
"mcpServers": {
"xyz-rubenayla-partle-marketplace": {
"url": "https://partle.rubenayla.xyz/mcp/"
}
}
} {
"servers": {
"xyz-rubenayla-partle-marketplace": {
"type": "http",
"url": "https://partle.rubenayla.xyz/mcp/"
}
}
} [mcp_servers.xyz-rubenayla-partle-marketplace] url = "https://partle.rubenayla.xyz/mcp/"
{
"$schema": "https://opencode.ai/config.json",
"mcp": {
"xyz-rubenayla-partle-marketplace": {
"type": "remote",
"url": "https://partle.rubenayla.xyz/mcp/",
"enabled": true
}
}
} openclaw mcp add xyz-rubenayla-partle-marketplace --url 'https://partle.rubenayla.xyz/mcp/' --transport streamable-http
mcp_servers:
xyz-rubenayla-partle-marketplace:
url: "https://partle.rubenayla.xyz/mcp/" {
"McpServers": {
"xyz-rubenayla-partle-marketplace": {
"Transport": "http",
"Url": "https://partle.rubenayla.xyz/mcp/"
}
}
} assistant mcp add xyz-rubenayla-partle-marketplace -t streamable-http -u 'https://partle.rubenayla.xyz/mcp/'
{
"mcpServers": {
"xyz-rubenayla-partle-marketplace": {
"type": "http",
"url": "https://partle.rubenayla.xyz/mcp/"
}
}
} The mcpServers block is a cross-client convention. Remote transports vary, so check your client's docs.
Every change we have recorded for this component, newest first. Security-relevant changes are always shown. ▲ marks a change for the better, ▼ a change for the worse; unmarked changes are neutral.
- 8 Sept 26 +1
- Stability: fail → pass ▲ security
- 5 Sept 26 −1
- Stability: pass → fail ▼ security
- 31 Aug 26 +12
- Judged manipulation: unverified → pass ▲ security
- Schema quality: unverified → excellent ▲ functional
- 30 Aug 26 −12
- Judged manipulation: pass → unverified ▼ security
- Tool “create_buy_request” rewrote its description, which is the text the model reads security
- Schema quality: excellent → unverified ▼ functional
- “create_buy_request” dropped the optional parameter “title” cosmetic
- 26 Aug 26 +2
- We updated how we score, so this day's move reflects our rubric, not a change to the server See what changed → functional
- 25 Aug 26 0
- Stability: 0.97 → pass security
- 24 Aug 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 93 to 97. That category is still filling its 30-day observation window: 28 days of observed history at the previous scan, 29 at this one. The score rises as the window fills, whether or not the server changes.
- 17 Aug 26 0
- HTTPS: unverified → pass ▲ security
Diagnostic detail from the automated scan of this channel: what the scanner observed at each step, so you can see exactly where a check passed or failed. It is informational only and never changes the trust score.
Captured 20 Sept 2026 · Probed https://partle.rubenayla.xyz/mcp/
TLS valid
Negotiated TLS 1.3 with TLS_AES_128_GCM_SHA256 .
| Subject | Issuer | Valid from | Valid until | Key | Signature | Serial |
|---|---|---|---|---|---|---|
| CN=rubenayla.xyz | CN=WE1,O=Google Trust Services,C=US | 1 Aug 2026 | 30 Oct 2026 | ECDSA 256 | ECDSA-SHA256 | 198c9c12a2cf127f0ecb0c8d8e2b88e4 |
| SANs: rubenayla.xyz, *.rubenayla.xyz | ||||||
| CN=WE1,O=Google Trust Services,C=US (CA) | CN=GTS Root R4,O=Google Trust Services LLC,C=US | 13 Dec 2023 | 20 Feb 2029 | ECDSA 256 | ECDSA-SHA384 | 7ff31977972c224a76155d13b6d685e3 |
| CN=GTS Root R4,O=Google Trust Services LLC,C=US (CA) | CN=GlobalSign Root CA,OU=Root CA,O=GlobalSign nv-sa,C=BE | 15 Nov 2023 | 28 Jan 2028 | ECDSA 384 | SHA256-RSA | 7fe530bf331343bedd821610493d8a1b |
Background: What to check on a remote MCP endpoint →
DNSSEC insecure
Validation of partle.rubenayla.xyz. — Not signed
| Zone | DS | Keys | Algorithms | Outcome |
|---|---|---|---|---|
| . | trust_anchor | 20326, 38696 | 8, 8 | Verified |
| xyz. | present | 3599, 18130 | 8, 8 | Verified |
| rubenayla.xyz. | absent | Unsigned (proven) parent-signed NSEC/NSEC3 proves an unsigned delegation |
Authentication No authorisation required
The endpoint answered without asking for a token. Anyone who knows the URL can reach it.
| Result | No authorisation required |
|---|---|
| HTTP status | 200 |
Background: How OAuth 2.1 works in the 2026 MCP spec →
Transports 2 probes
| Transport | URL | Outcome | Status | Location |
|---|---|---|---|---|
| streamable-http | https://partle.rubenayla.xyz/mcp/ | Verified | 200 | |
| http (plaintext) | http://partle.rubenayla.xyz/mcp/ | HTTPS enforced | 301 | https://partle.rubenayla.xyz/mcp/ |
The tools this component advertises to a client, with an estimated token cost for each. Expand a tool to see its parameters and schema. The per-tool counts are indicative and are not scored directly; the schema's total context footprint is one signal in Schema Quality & AI Usability. A tool's description is untrusted text the model reads on every call, which is what makes this list a security surface and not just an inventory: how tool poisoning works →
add_inventory_item ~695
Add an item to the caller's personal inventory. Authenticated. Required OAuth scope: `inventory:write`. One creation tool covers all lifecycle states — set ``status`` based on the user's intent: "I bought" → ``owned``, "I want" → ``wanted``, "I'm selling" → ``for_sale``. Either ``product_id`` (linked to an existing Partle product) or ``name`` (freeform) must be set. **Not idempotent** — each call creates a new row. Args: name: Freeform name for items not yet linked to a Partle product. Either ``name`` or ``product_id`` must be set. product_id: Link to a canonical Partle product. status: Lifecycle. One of: ``owned``, ``wanted``, ``for_sale``, ``sold``, ``discarded``. Default ``owned``. quantity: How many. Fractional allowed. Default 1. notes: Freeform multi-line text — the dumping ground for anything not modeled as a column: extra URLs, comments, where stored, condition narrative, purpose, source, history, log entries. Markdown is fine. **Put extra URLs here, not in another field.** acquisition_price: What the user paid. acquisition_currency: Currency of acquisition_price. purchased_at: ISO date (YYYY-MM-DD) when it was acquired. asking_price: When status=for_sale, asking price. asking_currency: Currency of asking_price. condition: Free string — typical: ``new``, ``like_new``, ``good``, ``fair``, ``poor``. external_link: **Primary** click-through URL only (source listing, vendor page, manufacturer page). Exactly one. Additional URLs go in ``notes`` as markdown links. external_id: Stable identifier from the source system, used as a **dedup key**. Per-user unique when set — same external_id can't appear twice for one user. Format is up to you (e.g. ``aliexpress:1005004714348221``, ``amazon:order/3024.../l…
| Name | Type | Req | Description |
|---|---|---|---|
| acquisition_currency | – | – | – |
| acquisition_price | – | – | – |
| api_key | – | – | – |
| asking_currency | – | – | – |
| asking_price | – | – | – |
| condition | – | – | – |
| external_id | – | – | – |
| external_link | – | – | – |
| name | – | – | – |
| notes | – | – | – |
| product_id | – | – | – |
| project | – | – | – |
| purchased_at | – | – | – |
| quantity | number | – | – |
| status | string | – | – |
No output schema declared.
No examples provided.
create_buy_request ~396
Post a public buy request — an ad asking suppliers to reach out. Use when the user wants others to know they're looking to buy something. **Independent of personal inventory** — inventory is the user's private workshop tracking; a buy request is a sales-facing ad on the public demand feed at /wanted. Authenticated. Required OAuth scope: ``inventory:write``. **Not idempotent** — each call creates a new public post. Args: name: Short scannable headline ("Looking for X"). Required. description: Plain text long-form — specs, constraints, delivery preference. The supplier reads this to decide whether they can fulfil. quantity: How many units the poster wants. Default 1. max_price: Optional ceiling per unit. currency: Currency for max_price (default €). contact: Free-form contact (email/phone/Telegram/etc.) shown publicly. Optional. Without it, suppliers can only respond via whatever channels you separately make available. reference_url: Link to a sample/datasheet/manufacturer page. product_id: Link to a canonical Partle product if asking for a specific known SKU. api_key: Optional API key (`pk_*`, generate at /account). Used when there is no OAuth token, and also when the OAuth token lacks the required scope — an explicitly passed key overrides an ambient token that is scoped too narrowly. An invalid or revoked token still fails regardless. Returns: The newly-created buy request, or ``{"error": ...}``.
| Name | Type | Req | Description |
|---|---|---|---|
| api_key | – | – | – |
| contact | – | – | – |
| currency | – | – | – |
| description | – | – | – |
| max_price | – | – | – |
| name | – | – | – |
| product_id | – | – | – |
| quantity | integer | – | – |
| reference_url | – | – | – |
No output schema declared.
No examples provided.
create_product ~1,006
Create a new product listing on Partle. Authenticated. Prefer **OAuth**: connect once via the consent flow on claude.ai (or any MCP client that supports OAuth) and the bearer token is attached automatically — no `api_key` parameter needed. **Fallback**: pass an `api_key` (prefix `pk_`, generate at /account) for programmatic or non-OAuth clients. Required OAuth scope: `products:write`. Use when the user wants to add an item for sale. For edits to an existing product, use `update_product` instead. **Images.** This tool creates text fields only — no image arg. Do **not** try to pass image bytes through a tool argument; phone-sized payloads blow past conversation context limits. The response includes a one-shot ``upload_url`` (signed, ~15 min TTL, bound to this product and your authenticated user). To attach an image from your code-execution sandbox, do **one** PUT request — no auth headers needed, the URL itself carries the credential: requests.put(result["upload_url"], data=open("/path/to/photo.jpg", "rb").read(), headers={"Content-Type": "image/jpeg"}) The bytes flow Python → HTTP body → Partle, never through the conversation. The URL works once and expires fast. Alternative if you don't have local bytes but have a public image URL: call ``upload_product_image(product_id, image_url=...)`` instead. **Duplicate prevention.** Same user, same product name (case- and whitespace-insensitive) returns 409 with `existing.id`, `existing.url`, **and a fresh `upload_url`** for that existing product — so if the user is just retrying with a photo, you can attach it directly to the existing listing without having to create or pick anything new. You can also call `update_product` to change fields. Don't retry blindly. **Idempotency.** Pass `idempotency_key` (any unique string per logical create — UUID or hash of the source…
| Name | Type | Req | Description |
|---|---|---|---|
| api_key | – | – | – |
| currency | – | – | – |
| description | – | – | – |
| idempotency_key | – | – | – |
| listing_type | string | – | – |
| name | string | yes | – |
| price | – | – | – |
| store_id | – | – | – |
| url | – | – | – |
No output schema declared.
No examples provided.
delete_inventory_item ~176
Permanently delete an inventory row. Authenticated. Required OAuth scope: `inventory:write`. Caller must own the item (404 otherwise). Hard delete — no soft-delete. Args: item_id: ID of the row to delete. api_key: Optional API key (`pk_*`, generate at /account). Used when there is no OAuth token, and also when the OAuth token lacks the required scope — an explicitly passed key overrides an ambient token that is scoped too narrowly. An invalid or revoked token still fails regardless. Returns: ``{"deleted": true, "id": item_id}`` on success, or ``{"error": ...}`` on auth / not-found.
| Name | Type | Req | Description |
|---|---|---|---|
| api_key | – | – | – |
| item_id | integer | yes | – |
No output schema declared.
No examples provided.
delete_product ~243
Permanently delete a product listing and all its images. Destructive. Authenticated. OAuth (scope `products:write`) preferred; `api_key` fallback. Use only when the user explicitly asks to remove a listing they own. Cannot be undone — there is no soft-delete or trash bin. Idempotent: deleting a product that no longer exists returns an error, not duplicate side effects. Caller must own the product. Args: product_id: ID of the product to delete. Get from `get_my_products`. api_key: Optional API key (`pk_*`, generate at /account). Used when there is no OAuth token, and also when the OAuth token lacks the required scope — an explicitly passed key overrides an ambient token that is scoped too narrowly. An invalid or revoked token still fails regardless. Omit when using OAuth. Returns: ``{"deleted": True, "product_id": int}`` on success, or ``{"error": ...}`` on auth/ownership failure.
| Name | Type | Req | Description |
|---|---|---|---|
| api_key | – | – | – |
| product_id | integer | yes | – |
No output schema declared.
No examples provided.
delete_product_image ~267
Remove a specific image from a product. Destructive, idempotent. Authenticated. OAuth (scope `products:write`) preferred; `api_key` fallback. Use when an image was uploaded by mistake or the merchant updated their listing. The product itself is preserved — only the image record and its file are removed. To remove the product entirely use `delete_product`. Args: product_id: ID of the product the image belongs to. image_id: ID of the image to delete. Visible in the `images` array of `get_product` responses. api_key: Optional API key (`pk_*`, generate at /account). Used when there is no OAuth token, and also when the OAuth token lacks the required scope — an explicitly passed key overrides an ambient token that is scoped too narrowly. An invalid or revoked token still fails regardless. Omit when using OAuth. Returns: ``{"deleted": True, "product_id": int, "image_id": int}`` on success, or ``{"error": ...}`` on auth/ownership failure.
| Name | Type | Req | Description |
|---|---|---|---|
| api_key | – | – | – |
| image_id | integer | yes | – |
| product_id | integer | yes | – |
No output schema declared.
No examples provided.
get_my_inventory ~367
List the caller's personal inventory items. Authenticated. Required OAuth scope: `inventory:read` (or pass an `api_key` for legacy/programmatic clients). Use this when the user asks "what do I own?", "what's on my wishlist?", "what am I selling?", etc. The returned rows include every status by default; pass `status` to filter. Args: status: Filter by lifecycle. One of: ``owned``, ``wanted``, ``for_sale``, ``sold``, ``discarded``. Omit for all. product_id: Filter to rows linked to a specific Partle product. project: Exact-match filter on the project tag. q: Substring search on `name` and `notes` (case-insensitive). limit: Page size, 1–200. Default 50. offset: Pagination offset. Default 0. api_key: Optional API key (`pk_*`, generate at /account). Used when there is no OAuth token, and also when the OAuth token lacks the required scope — an explicitly passed key overrides an ambient token that is scoped too narrowly. An invalid or revoked token still fails regardless. Omit when using OAuth. Returns: ``{"items": [...], "count": int}`` where each item carries status, quantity, name (or linked product), notes, prices, etc. On auth failure: ``{"error": ...}``.
| Name | Type | Req | Description |
|---|---|---|---|
| api_key | – | – | – |
| limit | integer | – | – |
| offset | integer | – | – |
| product_id | – | – | – |
| project | – | – | – |
| q | – | – | – |
| status | – | – | – |
No output schema declared.
No examples provided.
get_my_products ~222
List products created by the authenticated user. Authenticated. OAuth (scope `products:read`) preferred; `api_key` fallback. Use when the user asks "what have I listed?" or before bulk operations like updating prices across multiple of their products. Distinct from `search_products`, which searches the public catalog without owner scoping. Read-only. Args: limit: Max results (1–200, default 50). api_key: Optional API key (`pk_*`, generate at /account). Used when there is no OAuth token, and also when the OAuth token lacks the required scope — an explicitly passed key overrides an ambient token that is scoped too narrowly. An invalid or revoked token still fails regardless. Omit when using OAuth. Returns: A list of products in the same shape as `search_products`. Returns ``[{"error": ...}]`` on auth failure.
| Name | Type | Req | Description |
|---|---|---|---|
| api_key | – | – | – |
| limit | integer | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | array | yes | – |
No examples provided.
get_product ~182
Get the full record for a single product by its numeric ID. Use after `search_products` returns a candidate the user is interested in, when you need fields not in the search summary (full description, all images, sold status, expiration). Don't loop `get_product` over many search results — re-search with tighter filters instead. Read-only. No authentication. Args: product_id: Integer `id` from a `search_products` result, or visible in a Partle product page URL (`/p/<id>-<slug>`). Returns: A single product object with all fields, including the canonical `partle_url` to share with the user. Returns ``{"error": ...}`` if the ID does not exist.
| Name | Type | Req | Description |
|---|---|---|---|
| product_id | integer | yes | – |
No output schema declared.
No examples provided.
get_stats ~116
Get top-level Partle platform statistics. Use for size questions ("how big is Partle?", "how many stores does Partle cover?"). Aggregate counts only — no per-product or per-store data; use `search_products` / `search_stores` for that. Read-only. No authentication. Cheap, but rarely changes — long-running agents should cache the result. Returns: ``{"total_products": int, "total_stores": int, "description": str}``.
Input schema present but exposes no named parameters.
No output schema declared.
No examples provided.
get_store ~146
Get the full record for a single store by its numeric ID. Use after `search_stores` to retrieve fields not in the search summary (full address, owner profile, contact details). For a list of *products* in that store, call `search_products(store_id=…)` instead — this tool returns store metadata only. Read-only. No authentication. Args: store_id: Integer `id` from a `search_stores` result. Returns: A single store object with all fields. Returns ``{"error": ...}`` if the ID does not exist.
| Name | Type | Req | Description |
|---|---|---|---|
| store_id | integer | yes | – |
No output schema declared.
No examples provided.
get_upload_url ~393
Mint a one-shot signed upload URL for a product you own. Authenticated. OAuth (scope `products:write`) preferred; `api_key` fallback. Use this when you have **local image bytes** (a file the user attached, bytes you generated/downloaded in your sandbox) and you want to attach them to a product that already exists. Common cases: - `create_product` returned 409 (duplicate name) — the listing already exists; this tool gives you an upload URL for it without creating anything new. - You're adding a 2nd, 3rd, … photo to a product. The returned URL is valid for ~15 min, single product, signed with your authenticated identity. From your sandbox, do **one PUT**: requests.put(result["upload_url"], data=open("/path/to/photo.jpg", "rb").read(), headers={"Content-Type": "image/jpeg"}) No auth header on that PUT — the URL is the credential. If you have a public URL (not local bytes), use `upload_product_image(product_id, image_url=...)` instead. Args: product_id: Product to attach the future image to. You must own it. api_key: Optional API key (`pk_*`, generate at /account). Used when there is no OAuth token, and also when the OAuth token lacks the required scope — an explicitly passed key overrides an ambient token that is scoped too narrowly. An invalid or revoked token still fails regardless. Omit when using OAuth. Returns: ``{"upload_url": str, "upload_expires_in": int}``, or ``{"error": ...}`` on auth/ownership failure.
| Name | Type | Req | Description |
|---|---|---|---|
| api_key | – | – | – |
| product_id | integer | yes | – |
No output schema declared.
No examples provided.
mark_for_sale ~285
Move an inventory item to status=for_sale and set listing fields. Convenience wrapper over `update_inventory_item` that matches a natural user request ("list my drill for sale at 30€"). Sets all three columns (`status`, `asking_price`, `asking_currency`, and optionally `condition`) atomically. Authenticated. Required OAuth scope: `inventory:write`. Caller must own the item. Args: item_id: ID of the inventory row. asking_price: How much you're asking for it. Whole units, not cents. Required. asking_currency: Currency. Default `€`. condition: Free string describing the item's condition (e.g. ``like_new``, ``good``). Optional. api_key: Optional API key (`pk_*`, generate at /account). Used when there is no OAuth token, and also when the OAuth token lacks the required scope — an explicitly passed key overrides an ambient token that is scoped too narrowly. An invalid or revoked token still fails regardless. Returns: The updated inventory row, or ``{"error": ...}``.
| Name | Type | Req | Description |
|---|---|---|---|
| api_key | – | – | – |
| asking_currency | string | – | – |
| asking_price | number | yes | – |
| condition | – | – | – |
| item_id | integer | yes | – |
No output schema declared.
No examples provided.
mark_sold ~172
Mark an inventory item as sold (status=sold). Convenience wrapper over `update_inventory_item` for the natural "I sold the drill" request. Authenticated. Required OAuth scope: `inventory:write`. Caller must own the item. Args: item_id: ID of the inventory row. api_key: Optional API key (`pk_*`, generate at /account). Used when there is no OAuth token, and also when the OAuth token lacks the required scope — an explicitly passed key overrides an ambient token that is scoped too narrowly. An invalid or revoked token still fails regardless. Returns: The updated inventory row, or ``{"error": ...}``.
| Name | Type | Req | Description |
|---|---|---|---|
| api_key | – | – | – |
| item_id | integer | yes | – |
No output schema declared.
No examples provided.
search_products ~1,484
Search Partle's product catalog by name or description. CRITICAL SEARCH INSTRUCTION: Reason from the job to the product class first, then search with a descriptive product phrase (e.g. including substrate, material, or size class). DO NOT blindly search using the user's raw conversational words. Transform questions like 'what do I need to attach a mirror to a brick wall?' into a product phrase like 'heavy duty masonry wall anchor'. Two distinct modes: - **Default (no flags)** — fast keyword search. ~100ms. Acts like a normal "dumb" search box: matches the literal words you typed against product names and descriptions, with stemming. Good for queries where the user knows the product's likely name ("BC547", "Arduino Uno", "Bosch drill"). Returns noisy/wrong results on cross-language or attribute queries ("compost bin" matches Spanish "composta", not real composters). - **`super_search=True`** — slow, high-quality. ~1–2s. Run when the user describes what they want rather than naming it: cross-language ("Schraubenzieher Set" → real screwdriver sets even without German catalog entries), attribute-style ("small metal part with a flat head"), or any case where the default returns junk. Embeds the query with voyage-3-large, takes the cosine top-50 over the corpus (with an exact-name precision boost for part numbers), then a cross-encoder reranks them. The two modes are mutually exclusive in practice — pick one based on whether the user knows the product's name or is describing it. Use this when the user asks to find a specific product or browse products matching a query. Prefer over `search_stores` when the intent is product-led ("find a drill") rather than store-led. Use `get_product` afterwards if the user wants full details for one specific result. Read-only. No authentication. Rate-limited to 100 requests/hour per IP. Args:…
| Name | Type | Req | Description |
|---|---|---|---|
| has_price | – | – | – |
| limit | integer | – | – |
| max_price | – | – | – |
| min_price | – | – | – |
| offset | integer | – | – |
| query | string | yes | – |
| semantic | boolean | – | – |
| sort_by | – | – | – |
| store_id | – | – | – |
| super_search | boolean | – | – |
| tags | – | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | array | yes | – |
No examples provided.
search_stores ~230
Search or list stores in the Partle marketplace. Use for store-led questions ("what hardware shops are in Madrid?") rather than product-led ones (use `search_products` for that). Pass no query to browse the whole catalog. Read-only. No authentication. Rate-limited to 100 requests/hour per IP. Args: query: Free-text search over store name and address. Omit to list all stores in default order. limit: Max results (1–50, default 20). Returns: A list of stores with `id`, `name`, `address`, `lat`/`lon` (when geocoded), `homepage`, `type`, and `product_count` (active listings in the store — useful for competitive-landscape sizing without a separate `search_products` round-trip). Pass `id` to `search_products(store_id=…)` to filter the product catalog by that store.
| Name | Type | Req | Description |
|---|---|---|---|
| limit | integer | – | – |
| query | – | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | array | yes | – |
No examples provided.
search_wanted ~349
Browse public buy requests — what users are looking to buy but haven't found through normal supply. The demand side of Partle. Use this when an agent wants to **offer matches** (cross-reference open requests against `search_products` and surface hits) or just survey unmet demand. Every result is a public posting — users put these up specifically so suppliers can reach them. Buy requests are independent of personal inventory (which is private): these are sales-facing ads, not workshop tracking notes. Read-only. No authentication. Rate-limited 100 req/hour per IP. Args: query: Free-text filter over name + description (case-insensitive substring). Omit to list everything, newest first. limit: Max results (1–100, default 20). offset: Pagination offset. Returns: A list of open buy requests. Each includes ``id``, ``name`` (plus a deprecated ``title`` mirror of it), ``description`` (markdown — read the full text for specs and constraints), ``quantity``, ``max_price`` + ``currency`` (if the poster set a ceiling), ``contact`` (if they left an email/phone/handle), ``reference_url`` (sample or datasheet link if any), ``posted_by`` (display name), and ``created_at``. If the poster left a ``contact`` value, that's how a supplier should respond — Partle doesn't broker the conversation.
| Name | Type | Req | Description |
|---|---|---|---|
| limit | integer | – | – |
| offset | integer | – | – |
| query | – | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | array | yes | – |
No examples provided.
submit_feedback ~516
Report a problem with **the Partle marketplace API/MCP itself**. Authenticated. Prefer **OAuth**: connect once via the consent flow and the bearer token is attached automatically. **Fallback**: pass an `api_key` (prefix `pk_`, generate at /account). Required OAuth scope: `feedback:write`. Feedback is attributed to your account so reports are trustworthy and the channel can't be flooded anonymously. Scope — what this is for: - A Partle tool description is unclear or its parameters are surprising. - A Partle response is broken, malformed, or missing fields. - The Partle catalog is missing a category of products you'd expect. - Search relevance is off for a specific class of queries on Partle. Scope — what this is **NOT** for: - General complaints about tasks Partle isn't designed to do (Partle is a local-marketplace search/listing API — not a news API, an HTML hosting service, a portfolio-rebalancing app, a stock brokerage, or a generic dashboard SaaS). - Venting that an invented API key was rejected (Partle keys must be `pk_<hex>`; generate one at /account — don't fabricate them). - Asking the maintainers to do work the user requested but you can't do. If you can't fulfil a user request, tell the user — don't submit feedback about it here. Don't loop — each call adds a row and pages the maintainer. Resubmitting the same text within 24h is de-duplicated (returns the existing id). Args: feedback: Freeform text up to 5000 characters. Be specific — name the tool, the input that was confusing, and what you expected. api_key: Optional API key (`pk_*`, generate at /account). Used when there is no OAuth token, and also when the OAuth token lacks the required scope — an explicitly passed key overrides an ambient token that is scoped too narrowly. An invalid or revoked token still fails regardl…
| Name | Type | Req | Description |
|---|---|---|---|
| api_key | – | – | – |
| feedback | string | yes | – |
No output schema declared.
No examples provided.
update_inventory_item ~336
Patch an existing inventory item. Only provided fields change. Authenticated. Required OAuth scope: `inventory:write`. Caller must own the item (404 otherwise — we don't leak existence). Idempotent: calling twice with the same input yields the same final state. For lifecycle convenience, see `mark_for_sale` and `mark_sold` which set the right combination of fields atomically. Args: item_id: ID of the inventory row to update. Get from `get_my_inventory` or `add_inventory_item`'s return value. (every other param matches `add_inventory_item`; omit any field you don't want changed.) api_key: Optional API key (`pk_*`, generate at /account). Used when there is no OAuth token, and also when the OAuth token lacks the required scope — an explicitly passed key overrides an ambient token that is scoped too narrowly. An invalid or revoked token still fails regardless. Returns: The updated inventory row, or ``{"error": ...}`` on auth / not-found / validation failure.
| Name | Type | Req | Description |
|---|---|---|---|
| acquisition_currency | – | – | – |
| acquisition_price | – | – | – |
| api_key | – | – | – |
| asking_currency | – | – | – |
| asking_price | – | – | – |
| condition | – | – | – |
| external_id | – | – | – |
| external_link | – | – | – |
| item_id | integer | yes | – |
| name | – | – | – |
| notes | – | – | – |
| product_id | – | – | – |
| project | – | – | – |
| purchased_at | – | – | – |
| quantity | – | – | – |
| status | – | – | – |
No output schema declared.
No examples provided.
update_product ~377
Update an existing product listing. Only provided fields are changed. Authenticated. OAuth (scope `products:write`) preferred; `api_key` accepted as fallback. Only fields you pass are changed; omitted fields are preserved. Idempotent — calling twice with the same input yields the same final state. For creating a new listing, use `create_product` instead. Caller must own the product. Trying to update someone else's product returns an error. Args: product_id: ID of the product to update. Get from `create_product`'s return value, `get_my_products`, or `search_products`. name: New product name. Omit to leave unchanged. description: New description. Omit to leave unchanged. price: New price in whole currency units (e.g. 15.99 = €15.99). Max 100000. Omit to leave unchanged. currency: New currency symbol. Omit to leave unchanged. url: New merchant URL. Omit to leave unchanged. api_key: Optional API key (`pk_*`, generate at /account). Used when there is no OAuth token, and also when the OAuth token lacks the required scope — an explicitly passed key overrides an ambient token that is scoped too narrowly. An invalid or revoked token still fails regardless. Omit when using OAuth. Returns: The updated product record (full, not just the changed fields), or ``{"error": ...}`` on auth/ownership/validation failure.
| Name | Type | Req | Description |
|---|---|---|---|
| api_key | – | – | – |
| currency | – | – | – |
| description | – | – | – |
| name | – | – | – |
| price | – | – | – |
| product_id | integer | yes | – |
| url | – | – | – |
No output schema declared.
No examples provided.
upload_product_image ~502
Attach an image to an existing product by giving Partle a public URL to download the image from. Authenticated. OAuth (scope `products:write`) preferred; `api_key` fallback. **When to use this tool**: the image is already hosted at a public URL (a scraped product page, an Imgur link, a CDN URL the user provided). Partle's server fetches it and stores it. **When NOT to use this tool**: you have local image bytes (a file the user attached, or bytes you generated/downloaded in your sandbox). Sending those bytes through a tool argument blows past conversation context limits — phone-photo-sized payloads can be 6+ MB of base64. Instead, in your code-execution sandbox, POST the file directly to the HTTP endpoint with multipart encoding: requests.post( "https://partle.rubenayla.xyz/v1/external/products/{product_id}/images", files={"file": open("/path/to/photo.jpg", "rb")}, headers={"X-API-Key": "pk_..."}, ) Or, to create the listing and attach an image in one HTTP request: requests.post( "https://partle.rubenayla.xyz/v1/external/products", data={"metadata": json.dumps({"name": ..., "price": ...})}, files={"image": open("/path/to/photo.jpg", "rb")}, headers={"X-API-Key": "pk_..."}, ) Args: product_id: ID of the product to attach the image to. image_url: Publicly fetchable URL of the image. Server fetches it and stores it. api_key: Optional API key (`pk_*`, generate at /account). Used when there is no OAuth token, and also when the OAuth token lacks the required scope — an explicitly passed key overrides an ambient token that is scoped too narrowly. An invalid or revoked token still fails regardless. Omit when using OAuth. Returns: The created `ProductImage` record with its `id` (use for deletion) and storage path, or ``{…
| Name | Type | Req | Description |
|---|---|---|---|
| api_key | – | – | – |
| image_url | string | yes | – |
| product_id | integer | yes | – |
No output schema declared.
No examples provided.
What is the Partle MCP server?
Partle is an MCP server listed in the public MCP registry as xyz.rubenayla.partle/marketplace. Search products in nearby stores. Agents can also list items for sale on a user's behalf. This page covers its hosted endpoint (https://partle.rubenayla.xyz/mcp/).
Is the Partle MCP server safe to use?
Partle scores 74 out of 100 on VerifyMCP. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.
What tools does the Partle MCP server expose?
Partle exposes 21 tools: search_products, get_product, search_stores, get_store, get_stats, and 16 more. Their descriptions and schemas cost roughly 8,460 tokens of context every time the server is loaded.
Does the Partle MCP server require authentication?
No. We connected to Partle without credentials and it answered, so anything it exposes is reachable by anyone who knows the address.
Is the Partle MCP server still maintained?
Partle is still listed as active in the MCP registry. We last reached this channel on 20 September 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.