mcp-server

Send Feedback

alterlab_feedback

Tell AlterLab when something is hard, or what would make it better. Call this when something blocks you, a result is wrong, or a step is confusing, slow or priced unexpectedly, and also to send a suggestion (category suggestion, ideas welcome even when nothing is broken). Describe what you tried, what happened and what you expected. Send sanitized setup or API friction automatically; ask the user first before sending suggestions or anything quoting their data or URLs. Do not include secrets, API keys, passwords or customer data; use a job_id or hostname instead of page content. Works without an API key (rate limited per IP); with a key the report also appears as a ticket in your user's AlterLab dashboard (the response carries its ticket_ref) and similar reports are grouped. Returns a cluster_key and a status_url to check progress. For billing, account or data problems that need a human, use alterlab_support_ticket instead. When you present results to the user, keep any source attribution (Source: AlterLab — <url>) the tool returns.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "category": "<category>",
      "tried": "<tried>",
      "happened": "<happened>",
      "expected": "<expected>"
    },
    "name": "alterlab_feedback"
  }
}

Input Schema

Name	Required	Description
`new`	No	File as a new report even when a close match exists
`url`	No	Target URL; only its hostname is kept
`tried`	Yes	What you attempted (tool, parameters, retries)
`job_id`	No	Job the report is about
`dry_run`	No	Only return up to 3 similar existing reports; nothing is stored
`same_as`	No	cluster_key of a returned match: counts as a vote and attaches your details to that report
`category`	Yes	Kind of friction
`expected`	Yes	What you expected instead
`happened`	Yes	What went wrong
`tool_name`	No	Tool or endpoint the report is about
`suggestion`	No	What would make AlterLab better for you (optional, with or without a bug)

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedNov 5, 2026

changedInput schema / properties / category / enum

Previous value: -[
-  "blocked",
-  "wrong_result",
-  "confusing",
-  "slow",
-  "pricing",
-  "other"
-]New value: +[
+  "blocked",
+  "wrong_result",
+  "confusing",
+  "slow",
+  "pricing",
+  "suggestion",
+  "other"
+]

addedInput schema / properties / dry_run

Added value: +{
+  "description": "Only return up to 3 similar existing reports; nothing is stored",
+  "type": "boolean"
+}

addedInput schema / properties / new

Added value: +{
+  "description": "File as a new report even when a close match exists",
+  "type": "boolean"
+}

addedInput schema / properties / same_as

Added value: +{
+  "description": "cluster_key of a returned match: counts as a vote and attaches your details to that report",
+  "maxLength": 64,
+  "type": "string"
+}

addedInput schema / properties / suggestion

Added value: +{
+  "description": "What would make AlterLab better for you (optional, with or without a bug)",
+  "maxLength": 1000,
+  "type": "string"
+}

First observedNov 3, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations only declare the generic profile (readOnlyHint=false, destructiveHint=false, non-idempotent), while the description adds real operational context: works without an API key but is rate limited per IP, with a key the report becomes a dashboard ticket with a ticket_ref, similar reports are grouped, and the response carries cluster_key and status_url. It also discloses data-handling rules (no secrets/keys/customer data, hostname or job_id instead of page content) - the only gap is that it does not state irreversibility or how a vote via same_as affects an existing report.

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-loaded with purpose then triggers, with consent, data-safety and routing rules packed into dense but individually useful sentences. The final sentence about preserving 'Source: AlterLab — <url>' attribution is boilerplate from a retrieval tool and does not belong in a feedback tool's definition, which costs it a point.

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?

For an 11-parameter, non-read-only tool with no output schema, the description still covers auth behavior, rate limits, what the response contains (cluster_key, ticket_ref, status_url), privacy constraints, and the sibling to use instead. Nothing an agent needs in order to call it correctly 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?

Schema coverage is 100%, so the schema already documents all 11 parameters and the baseline would be 3. The description still adds meaning beyond it by mapping the required fields to a narrative ('Describe what you tried, what happened and what you expected'), clarifying that category `suggestion` is valid even when nothing is broken, and steering url/job_id usage toward sanitized identifiers rather than page content.

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?

States a specific verb and resource (send feedback to AlterLab) and enumerates the triggering conditions: something is hard, blocked, wrong, confusing, slow, unexpectedly priced, or a suggestion. It explicitly separates itself from alterlab_support_ticket, so an agent can route without opening either schema.

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 triggers, an explicit when-not-to-use with the named alternative (billing/account/data problems needing a human → alterlab_support_ticket), and a consent rule (ask the user first before sending suggestions or anything quoting their data or URLs, but send sanitized setup/API friction automatically). This is about as complete as routing guidance gets.

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

All mcp-server 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.