Skip to main content
Glama

send_feedback

Send your user's feedback to the Autoview team: a feature request, a bug report, a question, or anything else. Works with no account and no token (as a guest), or with your user's token. Each message is saved for a person to review before it goes to the team; there is no set response time. With a token, the account is attached on our side from the token, so do not add it. Never put passwords, API keys or other secrets in message. If your user wants an answer, put a way to reach them in contact (for example an email address), or with a token set contact to true to use the address on the account. Show your user the message and get their go-ahead before sending. message is up to 4000 characters. Limit: 2 per hour for each account, or for each guest. Returns { received, id, status, guest, remaining_this_hour, note }; pass note to your user. A refusal returns { error, code, fix }: bad_kind, message_empty, message_too_long, contact_too_long, invalid_token, feedback_rate_limited (with retry_at), feedback_unavailable, feedback_store_failed. Do what fix says.

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": {
      "kind": "<kind>",
      "message": "<message>"
    },
    "name": "send_feedback"
  }
}

Input Schema

NameRequiredDescriptionDefault
kindYesfeature_request, bug, question, or other
tokenNoyour Autoview account token — an av_mcp_ personal access token, generate one at /account/tokens/ on the Autoview site. Omit this if your MCP client already sends it as an `Authorization: Bearer` header (Claude Code, Cursor, and most non-browser clients do this automatically once configured). Optional here: leave it out to send as a guest.
contactNooptional: how to reach your user if they want a reply (for example an email address, up to 254 characters), or true to use the address on the account (token only). Omit for no reply.
messageYesyour user's feedback in their own words, up to 4000 characters. For a bug, say what was sent, what happened and what was expected; a trace or canonical_id from events helps.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.9/5.0
Behavior5/5

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

Beyond the annotations, the description discloses that messages are stored for human review, there is no set response time, and sending is limited to 2 per hour per account or guest. It also describes the return shape, the refusal error codes, and directs the agent to follow the provided fix.

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

Conciseness5/5

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

The description is front-loaded with the core purpose and then packs operational detail into dense, purposeful sentences. Nothing is wasted: constraints, return values, error handling, and safety instructions each earn their place.

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?

Despite having no output schema, the description explains the success response shape and the refusal error format. It also covers guest versus token behavior, rate limits, message length, and the user-consent requirement, leaving no material gap for correct invocation.

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 baseline is 3. The description adds useful meaning around token handling — that the account is attached server-side and should not be duplicated in the message — and clarifies that contact can be true with a token to use the account address. It also states the 4000-character message limit.

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 states a specific verb and resource: sending user feedback to the Autoview team, covering feature requests, bug reports, questions, or anything else. The scope is unambiguous and no sibling tool overlaps with this action.

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?

It explicitly covers when to use the tool (user wants to send feedback), how to operate without an account or with a token, and the requirement to show the user the message and get their go-ahead before sending. It also explains how to set contact for replies and warns never to include secrets.

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.