Skip to main content
Glama
RajGehlot28

@twitterapis/mcp

by RajGehlot28
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

twitter_feedback_send

Report product problems or gaps in twitterapis.com to its team from inside a session by drafting a feedback report to a local queue, then sending it only after user review.

Instructions

Report a product problem or gap in twitterapis.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 twitterapis tool call failed with an error that was not a missing key (401), credits (402), no linked session (409) or a rate limit (429), and the user had to work around it; the user asked for something no twitterapis 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) and returns a server id that twitter_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. "tweet/thread" 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. "twitter_tweet_thread returns 502 when the root tweet 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 twitterapis.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. First observedv0.9.9

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only declare readOnlyHint=false, destructiveHint=false, openWorldHint=true. The description adds substantial context beyond that: drafting sends nothing and needs no confirmation, must not be announced mid-task, sending posts each draft to POST /feedback, and returns a server id retrievable via twitter_feedback_get. No contradiction with the annotations.

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?

Long but information-dense and front-loaded: purpose first, then labelled WHEN TO DRAFT, FORMAT and REVIEW sections. Nearly every sentence carries a rule or constraint, though the volume is near the upper bound for a tool description.

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?

No output schema exists, and the description compensates by stating what each action returns (queued draft locally, listed draft ids, a server id from POST /feedback). For a 7-parameter, nested-object, 4-action tool this is complete.

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 nonetheless adds real meaning: the four-bullet 'details' format, the facts-only constraint (no secrets/names), the auto-attachment of the last failing call where evidence is left blank, and the requirement that 'ids' match what list showed and the user named.

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+resource: report a product problem or gap in twitterapis.com to its team, from inside the session. It also disambiguates its own multi-action nature (draft/list/send/discard) despite the 'send' name, and distinguishes itself from sibling tools like twitter_feedback_get and twitter_feedback_list by role.

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?

Explicitly enumerates when to draft (failed call not caused by 401/402/409/429, uncovered request, empty/wrong documented field, user frustration), enforces one-draft-per-issue, and defines the review path: list, then send only ids the user named, or discard. This is when/when-not/alternatives in full.

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