xyz.rubenayla.partle/marketplace

Tools

• add_inventory_item

  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.../line/1``, content hash). Leave null for handwritten items. project: Tag for grouping (e.g. "kitchen-renovation"). 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 inventory row (with embedded `product` if linked), or ``{"error": ...}`` on auth/validation failure.

  shallow
• create_account_api_key

  Create a full-access catalog/inventory API key. Requires OAuth security:write. The secret is returned ONCE. Store it securely; never include it in a public message or logs. This grants broader catalog/inventory access than a limited OAuth token. It cannot manage account settings or credentials through MCP. Each call creates a new key; do not retry blindly after a lost response.

  shallow
• create_buy_request

  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. title: Deprecated spelling of ``name``, accepted so existing clients keep working. Pass ``name`` instead; if both are given, ``name`` wins. 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": ...}``.

  shallow
• create_product

  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 listing) and a retry after a network failure returns the original response instead of creating a duplicate. Reusing a key with a different payload is a 422. Args: name: Product name. Required, 1–200 chars. description: Long-form product description. Optional. price: Price in whole currency units, **not** cents (e.g. ``15.99`` means €15.99). Max 100000. Omit for "ask the seller". currency: Currency symbol. Defaults to `€`. Use `$`, `£`, etc. url: Link to the merchant's product page. Optional but recommended. store_id: ID of the store this product belongs to. Omit for a personal listing not tied to any store. listing_type: ``in_stock`` (default) when the seller has the item and it can be bought now. ``tentative`` when they do not stock it and want to measure interest first — such a listing is kept out of normal search results and instead collects "I need this" presses. Only use ``tentative`` if the user explicitly said they are gauging demand; an item that is merely out of stock today is still ``in_stock``. If the user is looking to *buy* something nobody sells, use `create_buy_request` instead — that is the demand side and it is a different tool. idempotency_key: Optional retry-safety token. Unique per logical create. Send the same key on retries to get the same response. 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 product record including its new `id` and canonical `partle_url`. Share `partle_url` with the user. Returns ``{"error": ...}`` on auth, dedup, or validation failure (dedup also returns ``{"existing": {"id", "name", "url"}}``).

  shallow
• delete_inventory_item

  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.

  shallow
• delete_product

  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.

  shallow
• delete_product_image

  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.

  shallow
• get_account_settings

  Read your account ID, email, username and theme. Requires OAuth account:read. Passwords and key secrets are never returned. No other account can be selected. A null theme means no account preference has been set; the browser keeps its local choice.

  shallow
• get_my_inventory

  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": ...}``.

  shallow
• get_my_products

  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.

  shallow
• get_product

  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.

  shallow
• get_stats

  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}``.

  shallow
• get_store

  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.

  shallow
• get_upload_url

  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.

  shallow
• list_account_api_keys

  List your key IDs, labels, prefixes and dates, never secrets. Requires OAuth security:read.

  shallow
• list_connected_apps

  List apps with active access to your account and their permissions. Requires OAuth security:read.

  shallow
• mark_for_sale

  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": ...}``.

  shallow
• mark_sold

  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": ...}``.

  shallow
• revoke_account_api_key

  Immediately revoke one of your API keys. Requires OAuth security:write. Consumers using the key will lose access. For rotation, first install and test the replacement returned by rotate_account_api_key.

  shallow
• revoke_connected_app

  Revoke an app's access AND refresh tokens for your account. Requires OAuth security:write. This disconnects the app immediately. Revoking your own calling app also works, but subsequent requests will fail until you reconnect with consent.

  shallow
• rotate_account_api_key

  Create a replacement for your key, keeping the old key ACTIVE. Requires OAuth security:write. Returns the replacement secret ONCE with its new ID. Install it in the consumer, test it, then call revoke_account_api_key with previous_key_id. Do not revoke until the replacement is working. Each call creates a key; do not retry blindly after a lost response. Never publish the secret.

  shallow
• search_products

  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: query: Free-text search term. In default mode, treated as keywords (each word matched against product text). In `super_search=True`, treated as a natural-language description. min_price: Lower bound on price in EUR. Omit for no lower bound. Null-priced rows are NOT excluded by this filter — pass `has_price=True` if you need only priced listings. max_price: Upper bound on price in EUR. Omit for no upper bound. Tip — narrow by budget: `min_price=10, max_price=50, sort_by="price_asc", has_price=True`. Products without a listed price (a large fraction of the scraped catalog) sort last under either price ordering and are kept in results unless `has_price` filters them out. tags: Comma-separated tag filter (e.g. "electronics,bluetooth"). Tags are AND-ed together. store_id: Restrict results to a single store. Use the integer `id` from `search_stores` results. sort_by: One of `price_asc`, `price_desc`, `name_asc`, `newest`, `oldest`. Omit to use the default search-relevance ranking. has_price: When True, exclude products without a listed price (~most of the scraped catalog). Use this for competitive pricing or budget-bounded shopping. When False, return only null-priced listings (rarely useful). Omit to include both. semantic: Legacy flag. Pure vector ordering, ~250ms. Mostly superseded by `super_search=True` (which uses the same vector retrieval plus a cross-encoder rerank for materially better ordering at the cost of another ~700ms). Keep using it only if you specifically want vector retrieval *without* the rerank. super_search: **Enable for natural-language / "describe what I want" queries.** ~1–2s. Embeds the query with voyage-3-large, takes the cosine top-50 (with a precision boost for exact-name matches like part numbers / SKUs), then a cross-encoder reranks them. Use whenever the user is describing rather than naming — cross-language ("Schraubenzieher Set"), attribute-style ("small black metal bracket"), or any case where the default keyword path returns junk. Don't combine with cheap browse-style queries where the user typed an exact product name — keyword default is faster there. On `relevance_score` here: better than the bi-encoder cosine, but still not a "did I find what the user wanted" gauge. Behavior to expect: gibberish or fully-off-topic queries cap around 0.35; loosely-related catalogue clusters can score 0.7+ even when no item truly matches (a "ceramic vase" query in a catalog with no vases but many ceramic flowerpots will still score high). **Read the product names** before claiming a match. The score is most useful as a relative signal within one result set — a sharp drop between rank N and N+1 marks where the catalog stops being useful for this query. limit: Max results (1–100, default 20). Larger limits are slower and consume rate budget faster. offset: Skip this many results before returning. Use for pagination (offset += limit on each follow-up call). Returns: A list of products. Each includes `id`, `name`, `price`, `currency`, `url`, `description`, `store` (id/name/address), `tags`, `images`, a canonical `partle_url`, and `relevance_score` (cosine similarity 0–1 between the query and the product's embedding when a query was provided; `None` otherwise). **Always share `partle_url` with the user so they can view the listing.** Caveat on `relevance_score`: it is monotonic *within a single search result set* (useful for spotting a big drop-off between rank 3 and rank 4), but its absolute value is not well-calibrated across queries — most results land in 0.55–0.80 regardless of whether the catalog has truly relevant items. Don't infer "this is a great match" from a 0.75 score alone.

  shallow
• search_stores

  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.

  shallow
• search_wanted

  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.

  shallow
• set_account_username

  Set your username once, only if unset. Requires OAuth account:write. Use 3–20 letters, digits, underscores or dashes. Existing usernames cannot be changed. Ask the user which public username they want before setting it.

  shallow
• submit_feedback

  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 regardless. Omit when using OAuth. Returns: ``{"id": int, "message": "Thanks for the feedback!"}`` on success, or ``{"error": ...}`` on auth, rate-limit, or validation failure.

  shallow
• update_account_settings

  Set your account theme to light, dark, or system. Requires OAuth account:write. The website applies it on login, reload or return to its tab. This only changes the theme; passwords, roles and sign-in providers cannot be changed.

  shallow
• update_inventory_item

  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.

  shallow
• update_product

  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.

  shallow
• upload_product_image

  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 ``{"error": ...}`` on validation/auth failure.

  shallow

Embed this server’s score

Tool count and median score across every tool in this server’s corpus — honest in a way a single cherry-picked tool’s badge wouldn’t be.

[![Vouch score](https://vouch.tools/api/servers/73c78f30-bcc8-4950-8307-a012a7cea1a9/badge.svg)](https://vouch.tools/servers/73c78f30-bcc8-4950-8307-a012a7cea1a9)