Skip to main content
Glama
Sign In

SupaBird

by io.supabird.api
OverviewDiscussionsAdmin

search_tweets

Read-onlyIdempotent

Find X/Twitter posts with SupaBird Magic Search. The user speaks normally. Pass their request as prompt. Do not convert it into Twitter operators (from:, min_faves:, filter:, since:).

    HOW MANY POSTS:
    - Default limit is 5. Omit limit unless the user asked for a specific number.
    - If they ask for a number, pass that as limit (1–20).
    - The result may contain fewer posts than limit when fewer matches pass.

    RESPONSE FORMATTING:
    - Always display the full tweet text as-is, never summarize or shorten it
    - Only truncate if a tweet exceeds 400 characters, and if so, clearly note "[truncated, ask to display full tweet]" at the end
    - Do not paraphrase or editorialize tweet content when displaying results
    - Include the author and the url for each post

    OFFER NEXT ACTIONS:
    - After every response, offer next actions
    - Tell user they can select a post and ask SupaBird to rewrite it in their style, or create a custom post and schedule it

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": {
      "prompt": "<prompt>"
    },
    "name": "search_tweets"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNoHow many matching posts to return. Default 5. Set only when the user names a count.
promptYesThe user's search request in plain language. Example: "recent build in public posts with under 5 likes".

Schema Changelog

Changes observed during successful MCP inspections.

No schema history has been recorded yet.

TDQS

A3.7/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the safety profile is covered. The description adds genuinely useful behavior beyond that: the result may return fewer posts than limit when fewer matches pass. However, most of the remaining text is output-presentation policy for the assistant rather than tool behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose is front-loaded and the ALL-CAPS sectioning makes it scannable, but a large share of the text is response-formatting and next-action scripting (truncation at 400 chars, offering rewrite/schedule follow-ups) that is agent-output policy rather than tool selection or invocation help. Tightening to the search-specific guidance would improve it.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a two-parameter read tool with no output schema, the description covers how to form the query, how to size the result, and roughly what comes back (author, url, full text). It omits ordering/recency defaults and any note on empty-result handling, but nothing critical to calling it correctly is 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% and both parameters are documented in the schema, so baseline is 3. The description exceeds it by reinforcing the limit default of 5 and the range 1–20 and by specifying that prompt must stay in plain language rather than be rewritten as operators, which is real semantic guidance.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ("Find X/Twitter posts") and brands the mechanism ("SupaBird Magic Search"), and the natural-language instruction makes clear this is a plain-text query tool rather than an operator-based filter. It does not explicitly name a sibling like search_community_tweets or get_user_last_tweets, so differentiation is inferred rather than stated.

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?

Gives concrete invocation guidance: pass the user's request verbatim as prompt, do not convert to Twitter operators, omit limit unless a count was named. It lacks explicit when-to-use-this-vs-a-sibling routing despite many overlapping search/get tools, so ceiling is 4 rather than 5.

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

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