Skip to main content
Glama

Report website friction

report_friction

Report a problem you ran into while using a website or one of its tools (MCP, WebMCP or API), so the site's owners can fix it. Call this whenever you get stuck, are slowed down, or have to work around something on a website: information you couldn't find (e.g. shipping costs, return policy, sizes), a button or link that didn't work, a form that rejected valid input, a checkout or payment error, a confusing layout, a tool that failed or returned the wrong thing, no tool for what you needed, or anything that made the task harder than it should be. Report even if you eventually succeeded. Report each problem once, not again on every retry. If you found a way past it, say what worked, so other agents can try it. Be specific and factual: name the exact button or field involved and copy any error text word for word. Do not include personal data such as card numbers, passwords or addresses.

Input Schema

NameRequiredDescriptionDefault
goalYesWhat you were trying to accomplish, e.g. "Find the shipping cost to Canada before buying".
siteYesThe website's domain, e.g. "acme.com".
toolNoThe name of the tool or API operation involved, e.g. "update_cart" or "POST /cart". If no tool existed for what you needed, name the tool you looked for. Leave out when you were using the site's pages.
agentNoWhich agent you are: your product or framework and your model, e.g. "Claude in Chrome, Claude Sonnet 5.5" or "browser-use, GPT-5". Leave out if you don't know.
browserNoWhere the browser you are using runs: "user" = the person's own browser on their device; "cloud" = a hosted, remote or headless browser; "unknown" if you can't tell.
channelNoHow you were using the site: "browser" = clicking through its pages; "webmcp" = a WebMCP tool on the page; "mcp" = the site's MCP server; "api" = its API.
elementNoThe exact button, link or form field involved, named as it appears on the page, e.g. "'Continue to payment' button" or "'ZIP code' field". Leave out if the problem wasn't about one element (e.g. information you couldn't find).
page_urlYesThe full URL of the page where the problem happened, or of the MCP server or API endpoint if you were calling a tool.
severityYeslow = minor annoyance; medium = slowed you down; high = needed a workaround or guess; blocking = you could not complete the task.
error_shownNoAny error or warning the page showed, copied word for word. Write "none" if the page showed no error.
what_workedNoIf you got past the problem, the step that worked, e.g. "Reloading the page and clicking Continue again" or "Using the Guest checkout link under the sign-in form". Leave out if nothing worked.
what_i_triedYesThe concrete steps you took, in order, e.g. "Searched the product page, opened the FAQ, clicked 'Shipping' in the footer".
what_went_wrongYesWhat actually happened and why it was a problem.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • addedInput schema / properties / channel
      Added value: +{
      +  "description": "How you were using the site: \"browser\" = clicking through its pages; \"webmcp\" = a WebMCP tool on the page; \"mcp\" = the site's MCP server; \"api\" = its API.",
      +  "enum": [
      +    "browser",
      +    "webmcp",
      +    "mcp",
      +    "api"
      +  ],
      +  "type": "string"
      +}
    • changedInput schema / properties / page_url / description
      Previous value: -"The full URL of the page where the problem happened."New value: +"The full URL of the page where the problem happened, or of the MCP server or API endpoint if you were calling a tool."
    • addedInput schema / properties / tool
      Added value: +{
      +  "description": "The name of the tool or API operation involved, e.g. \"update_cart\" or \"POST /cart\". If no tool existed for what you needed, name the tool you looked for. Leave out when you were using the site's pages.",
      +  "maxLength": 200,
      +  "minLength": 1,
      +  "type": "string"
      +}
    • addedInput schema / properties / what_worked
      Added value: +{
      +  "description": "If you got past the problem, the step that worked, e.g. \"Reloading the page and clicking Continue again\" or \"Using the Guest checkout link under the sign-in form\". Leave out if nothing worked.",
      +  "maxLength": 1000,
      +  "minLength": 1,
      +  "type": "string"
      +}
  2. First observed

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare destructiveHint=false and idempotentHint=false; the description adds real value on top by explaining the intended destination ('so the site's owners can fix it'), the dedup behavior expected of a non-idempotent submit, and a hard privacy constraint ('Do not include personal data such as card numbers, passwords or addresses'). It stops short of describing what happens after submission or any rate/confirmation behavior.

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?

Front-loads purpose, then call conditions, then content guidance; the ordering is logical and each block earns its place. The middle enumeration of example failures is somewhat list-heavy and could be trimmed without losing meaning.

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 13-parameter, 6-required submission tool with no output schema, the description supplies the intent, the trigger conditions, and the privacy/verbatim-copying rules an agent needs to fill it correctly. What happens after submission is left unspecified, but the schema carries all field semantics, so the description is adequately complete.

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%, so params are documented; above that baseline the description adds filling guidance that maps to specific fields — name the exact element ('what_worked', 'element'), copy error text verbatim ('error_shown'), and explain the workaround. This raises it above a plain 3 without fully walking each of the 13 fields.

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?

States a clear verb ('Report') and resource ('a problem you ran into while using a website or one of its tools') with concrete scope covering browser, MCP, WebMCP, and API channels. It reads as a specific action an agent can identify, though it does not explicitly distinguish itself from the sibling get_site_tips.

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?

Gives explicit when-to-use criteria ('whenever you get stuck, are slowed down, or have to work around something') backed by an extensive enumeration of triggering situations, plus an exclusion ('Report each problem once, not again on every retry') and a positive edge case ('Report even if you eventually succeeded'). This is unusually complete routing guidance.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources