Partle Marketplac

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.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`api_key`	No
`feedback`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedJun 2, 2026

addedInput schema / properties / api_key

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Api Key"
+}

AddedApr 3, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Despite annotations only providing safety hints (readOnlyHint=false, destructiveHint=false), the description enriches behavioral understanding substantially. It explains authentication requirements (OAuth scope, api_key fallback), attribution to the user's account, deduplication within 24h, and the side effect that each call adds a row and pages the maintainer. This goes far beyond structured annotations and aligns with them.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

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

The description is longer than average but well-structured with clear headings, bullet lists, and a logical flow from purpose to auth to scope to arguments. Every sentence has a purpose, though some examples in the 'not for' list could be trimmed without losing meaning. The front-loading of the core purpose is excellent.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description is comprehensive for a low-complexity tool with 2 parameters and no output schema. It covers the exact return format, authentication paths, error behavior, scoping rules, and deduplication. There is no missing information an agent would need to invoke this tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema offers no descriptions for parameters, so the description fully compensates. It explains 'feedback' is freeform text up to 5000 characters and advises specificity. For 'api_key', it clarifies when to use it, how it overrides an OAuth token, and that invalid keys still fail. This adds meaning beyond the bare schema.

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 opens with a clear statement: 'Report a problem with the Partle marketplace API/MCP itself.' This identifies the exact verb (report) and resource (Partle API/MCP), and the scope section explicitly differentiates it from sibling tools by listing what it is and is not for, making it unmistakable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit 'Scope — what this is for' and 'Scope — what this is NOT for' sections, giving concrete use cases and exclusions. It also warns against common misuse (e.g., submitting feedback for user requests that can't be fulfilled) and advises alternatives ('tell the user — don't submit feedback about it here'). This is exemplary usage guidance.

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

All Partle Marketplac tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?