Skip to main content
Glama
Sign In

WA MCP

by com.wa-mcp
OverviewDiscussionsAdmin

report_feedback

Sends a bug report, feature request or message from the user to the WA MCP developers. It's stored with the user's account and phone number so we can follow up; nothing is posted publicly. Each call creates a new report and returns its feedback_id, so call it once per issue. Use when the user reports a bug, asks for a feature, or wants to contact us. Works on the free plan too. We reply only by email: before sending, tell the user that giving an email is optional and only needed if they want to be notified once it's addressed or answered, and pass it in email if they give one.

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": {
      "type": "<type>",
      "title": "<title>",
      "description": "<description>"
    },
    "name": "report_feedback"
  }
}

Input Schema

NameRequiredDescriptionDefault
typeYesbug_report for something broken, feature_request for a request, general for anything else.
emailNoOptional. The email address the user gave for our reply. Only an address the user typed for this; never one taken from their chats or contacts. Omit it if they didn't give one.
titleYesA one-line summary in English, under 80 characters. Translate it if the user wrote in another language.
contextNoOptional. Tool names, error messages or chat details that help reproduce it. No message contents unless the user agrees. If the user didn't write in English, add their language and their own words as they wrote them.
descriptionYesWhat happened or what the user wants, in English, keeping the user's details (translate it if they wrote in another language). For bugs, include what they asked for and what went wrong.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / email
      Added value: +{
+  "description": "Optional. The email address the user gave for our reply. Only an address the user typed for this; never one taken from their chats or contacts. Omit it if they didn't give one.",
+  "type": "string"
+}
  2. Changed3 schema fields changed
    • changedInput schema / properties / context / description
      Previous value: -"Optional. Tool names, error messages or chat details that help reproduce it. No message contents unless the user agrees."New value: +"Optional. Tool names, error messages or chat details that help reproduce it. No message contents unless the user agrees. If the user didn't write in English, add their language and their own words as they wrote them."
    • changedInput schema / properties / description / description
      Previous value: -"What happened or what the user wants, in the user's words. For bugs, include what they asked for and what went wrong."New value: +"What happened or what the user wants, in English, keeping the user's details (translate it if they wrote in another language). For bugs, include what they asked for and what went wrong."
    • changedInput schema / properties / title / description
      Previous value: -"A one-line summary, under 80 characters."New value: +"A one-line summary in English, under 80 characters. Translate it if the user wrote in another language."
  3. Changed4 schema fields changed
    • addedInput schema / properties / context / description
      Added value: +"Optional. Tool names, error messages or chat details that help reproduce it. No message contents unless the user agrees."
    • addedInput schema / properties / description / description
      Added value: +"What happened or what the user wants, in the user's words. For bugs, include what they asked for and what went wrong."
    • addedInput schema / properties / title / description
      Added value: +"A one-line summary, under 80 characters."
    • addedInput schema / properties / type / description
      Added value: +"bug_report for something broken, feature_request for a request, general for anything else."
  4. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the annotations, it discloses that reports are stored with the user's account and phone number, are not posted publicly, return a feedback_id, and should be created once per issue. It also explains that replies happen only by email and that email consent must be obtained first, which is substantial behavioral context for a write operation.

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 front-loaded with the action and audience, then moves into storage behavior, call frequency, triggers, and email handling. It is somewhat long and repeats the bug/feature/contact categories, but nearly every sentence adds operational value.

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 a create-style feedback tool with no output schema, it covers the important gaps: privacy and storage, non-public visibility, non-idempotent behavior via feedback_id and one-per-issue guidance, free-plan availability, and the email reply workflow. An agent has enough information to call it correctly and set user expectations.

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?

The schema already documents all five parameters thoroughly, including the email restriction and enum meanings. The description still adds useful meaning by explaining that email is only for notification after the issue is addressed and that the agent should tell the user it is optional before passing it in `email`.

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: it sends a bug report, feature request, or message to the WA MCP developers. That clearly distinguishes it from messaging siblings such as send_message because the audience is the developers, not another chat contact.

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

Usage Guidelines4/5

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

It gives explicit triggers: the user reports a bug, asks for a feature, or wants to contact the team. It also says to call it once per issue and explains the email consent step. It does not name when not to use it or point to a specific alternative sibling, so it stops short of a 5.

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

All WA MCP toolsInspect
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