Skip to main content
Glama
Sign In

Joeb

by com.joebapp
OverviewDiscussionsAdmin

Send feedback

send_feedback
Destructive

Send the Joeb team feedback or a bug report on the user's behalf.

message is what went wrong with Joeb or what the user wants changed, 1 to 1,000 characters of plain text. For a bug, say what was asked, what happened and what was expected. Never include the conversation itself, résumé or profile content, contact details, or other personal information; describe the problem in your own words. category is "bug", "feature_request" or "other"; omit it when none fits.

Joeb stores the message and its category with the user's account, along with the website of the assistant that sent it, and the Joeb team reads it. Nothing comes back through this tool: there is no answer to wait for, and no tool reads or changes a sent report. Each call sends a new report, so send a report once, and don't send one again after it went through.

Limited to 5 reports per hour per user, shared with the feedback form in the Joeb web app and browser extension. Past the limit the call fails with an error saying how many seconds to wait.

Returns a line confirming the report was sent.

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

Input Schema

NameRequiredDescriptionDefault
messageYesWhat went wrong with Joeb or what should change, in plain text, 1 to 1,000 characters. No conversation transcripts or personal information.
categoryNo"bug", "feature_request" or "other". Omit it when none fits.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Goes well beyond the annotations by disclosing what is persisted and to whom (message, category, sending assistant's website, stored on the user's account, read by the Joeb team), that nothing is returned or readable afterwards, that calls are non-idempotent, and the 5-per-hour quota with the exact error behavior past the limit.

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 the purpose, then moves through message content, privacy, storage/return behavior, and rate limits in a logical order. A few clauses are near-duplicates of the schema (the 1–1,000 character range appears twice), but nothing is filler.

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 two-parameter write tool with no output schema, everything an agent needs is present: content rules, privacy constraints, the one-shot semantics, the rate limit and its failure mode, and what the call returns.

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 still adds substantive content guidance the schema lacks, such as what to include for a bug (what was asked, what happened, what was expected) and an explicit list of content to exclude (transcripts, résumé, contact details).

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 the Joeb team feedback or a bug report") plus on whose behalf ("the user's behalf"). No sibling tool is remotely similar, and the description makes the outbound-report nature 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?

Gives explicit conditions for use (bug vs. feature request), tells the agent to omit `category` when none fits, names the alternative channel (the feedback form in the web app and browser extension) that shares the same quota, and warns against resending a report that already went through.

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

All Joeb 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