Skip to main content
Glama
RajGehlot28

@twitterapis/mcp

by RajGehlot28
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

twitter_feedback_list

Read-only

List feedback reports your account has sent to twitterapis.com, newest first, to review past reports or find a report ID for full status lookup.

Instructions

List the feedback reports this account has already SENT to twitterapis.com, newest first. Use it when the user asks what they have reported, or to find the server id of an earlier report so twitter_feedback_get can read its full status. NOT the same as twitter_feedback_send action "list", which shows local drafts that have not been sent yet. Each item carries id, type, title, area, status (new, triaged, shipped or declined), the team's response if any, created_at and updated_at, and never details or evidence, so paging this can never bulk-export a report's body: read one by id with twitter_feedback_get for that. Page with cursor while next_cursor is non-null. Free per call, and shares a 10-per-minute limit with the other feedback tools.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
typeNoOptional. Return only reports of this kind. Anything else is rejected with 400 naming type.
limitNoMax reports to return, 1 to 100. Defaults to 25. Anything outside that range is rejected with 400 naming limit.
cursorNoOpaque continuation token from a previous response's next_cursor. Omit it to start from the newest report. A cursor that cannot be decoded is a 400 naming cursor, never a silently empty page.
statusNoOptional. Return only reports in this state. Anything else is rejected with 400 naming status.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.9.9

TDQS

A4.7/5.0
Behavior5/5

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

Beyond the annotations (readOnlyHint=true, destructiveHint=false, openWorldHint=true), the description discloses output fields, the deliberate omission of details/evidence, pagination via cursor and next_cursor, and a shared 10-per-minute rate limit. These are important operational traits not captured by the structured metadata.

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 definition is front-loaded with purpose and then efficiently layers usage, sibling distinction, output caveats, pagination, and rate limits. Despite its length, every sentence adds necessary context for this tool, and there is no redundant 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?

With no output schema, the description compensates by naming the returned fields and explicitly stating what is never returned. It also covers pagination, rate limits, and the alternative read path, making it complete enough for an agent to invoke and interpret the tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all four parameters (type, limit, cursor, status) are already well documented in the input schema. The description adds little parameter-level meaning beyond restating cursor paging and newest-first ordering; baseline 3 applies.

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 first sentence gives a specific verb (List), resource (feedback reports), scope (this account, already SENT), and ordering (newest first). It further distinguishes the tool from the similarly named twitter_feedback_send local-draft list and points to twitter_feedback_get for report bodies, so an agent can select it correctly.

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 states when to use it ('when the user asks what they have reported, or to find the server id of an earlier report') and names the contrasting alternative (twitter_feedback_send action 'list' shows local drafts). The routing to twitter_feedback_get for full status makes the boundary complete.

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