Skip to main content
Glama
redditapis

RedditAPIs

by redditapis
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

reddit_feedback_send

Report redditapis.com bugs, missing features, or ideas by drafting them locally, then sending only after user review.

Instructions

Report a product problem or gap in redditapis.com to its team from inside this session, the way Claude Code's own feedback tool works: a report is DRAFTED to a local queue first (action "draft", the default) and SENT only after the user reviews it. Drafting sends nothing, needs no confirmation, and should not be announced mid-task. WHEN TO DRAFT, only at high-signal moments: a redditapis tool call failed with an error that was not a missing key (401), credits (402) or a rate limit (429), and the user had to work around it; the user asked for something no redditapis tool covers; a documented field came back empty or wrong; the user was clearly frustrated with a result. One draft per distinct issue, never twice for the same one. FORMAT for details, four labelled bullets in this order: 'What happened:' observed vs expected, exact error text if short. 'What the user said:' quoted verbatim, or 'user did not comment'. 'Repro:' the minimal call that reproduces it. 'Evidence:' tool name, endpoint, HTTP status, request id (the last failing call is attached automatically where you leave a gap). Facts only: no guessing, no API keys or secrets, no personal names. REVIEW: when the user asks to see or send feedback, call action "list", then action "send" with ONLY the draft ids the user named in their own message, or action "discard". Sending posts each draft to POST /feedback (free, not metered) and returns a server id that reddit_feedback_get can check later.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idsNoFor action "send" or "discard": the draft ids to act on, exactly as shown by action "list" and named by the user.
areaNoOptional. The endpoint or feature the report is about, e.g. "posts/comments" or "monitoring". At most 80 characters.
typeNoRequired for a draft. "bug": a tool or endpoint misbehaved. "idea": a change that would have made the task easier. "missing_capability": the user needed something no tool provides.
titleNoRequired for a draft. One specific line, at most 120 characters, naming the tool or endpoint and the defect, e.g. "reddit_post_comments returns 502 when the post is deleted".
actionNoWhat to do. "draft" (default) queues a new report locally and sends nothing. "list" shows the pending drafts with their ids. "send" posts the drafts named in ids to redditapis.com; use it only for ids the user named. "discard" drops the drafts named in ids.
detailsNoRequired for a draft. At most 8000 characters, four labelled bullets in order: What happened, What the user said (verbatim), Repro, Evidence.
evidenceNoOptional identifiers only, never payloads: {tool, endpoint, status, request_id}. Whatever you leave out is filled from the last failing call in this session; mcp_version and client are always attached.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.5.3

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only give readOnlyHint=false, destructiveHint=false, openWorldHint=true; the description adds substantial context beyond that: drafting is local and 'sends nothing, needs no confirmation', sending posts to POST /feedback, is free/not metered, and returns a server id checkable via reddit_feedback_get. It also discloses the auto-attach of the last failing call and auto-filled evidence fields.

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?

It is front-loaded with the core draft-then-send concept and organized into clear WHEN/FORMAT/REVIEW blocks, so it scans well. It runs long and some content (the four-bullet detail format) is duplicated from the schema, costing the top score.

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 7-parameter, multi-action, nested-object tool with no output schema, the description covers the full lifecycle: when to draft, the report format, how review/send/discard work, and what sending returns. Nothing an agent needs to invoke it correctly appears to be 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 every parameter and the enum values; the baseline would be 3. The description nonetheless adds meaning: the four labelled bullets for 'details', the fact that only user-named ids may be sent, and the auto-fill behaviour for omitted evidence fields. It reinforces rather than merely repeats the schema.

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 ('Report a product problem or gap in redditapis.com to its team') and distinguishes itself from its siblings (reddit_feedback_list, reddit_feedback_get) by centering the draft/send workflow. An agent can tell what this tool is for without opening the 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?

The 'WHEN TO DRAFT' block gives explicit trigger conditions (failed call that is not 401/402/429, uncovered request, wrong/empty field, user frustration), an explicit exclusion list, and a cadence rule ('one draft per distinct issue, never twice'). The REVIEW block names the alternatives (list/send/discard) and the condition that selects each.

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

Deploy Server

Other Tools