Skip to main content
Glama
Sign In

TwittrAPI

by io.github.twittrapi
OverviewDiscussionsAdmin

Get relationships with many accounts

get_friendships_batch
Read-onlyIdempotent

Check whether one account follows up to 50 others, and whether they follow it back, in one call. Returns raw JSON: one relationship per target, in order, plus errors for handles that could not be looked up.

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": {
      "sourceUsername": "<sourceUsername>",
      "targetUsernames": "<targetUsernames>"
    },
    "name": "get_friendships_batch"
  }
}

Input Schema

NameRequiredDescriptionDefault
max_charsNoMaximum characters of JSON to return (default 50000). Longer output is cut with a [TRUNCATED] marker. Lower it to save context, raise it if you need the full response.
sourceUsernameYesThe account to compare with the others, e.g. "jack" (a leading @ is fine).
targetUsernamesYesAccounts to check, 1 to 50 X handles (a leading @ is fine). Billed as one call per handle.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive and open-world, so the safety bar is met. The description adds genuine behavioral context beyond that: output is raw JSON, results preserve target order, and unresolvable handles yield per-item errors rather than failing the whole call. It omits the per-handle billing/cost note that lives only in the schema.

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?

Two sentences, front-loaded with the operation and its batch scope, then the return shape. Nothing is padded or repeated from the title.

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?

With no output schema, the description steps in to describe return shape (one relationship per target, ordered, plus errors), which is the key missing piece. It stops short of saying what fields a 'relationship' object contains (e.g. which direction flags), leaving a small ambiguity for an agent parsing results.

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 coverage is 100%, so all three parameters including max_chars are documented in the schema itself. The description only reinforces the 50-target ceiling and the ordering of targetUsernames; it adds no format, validation, or cost detail beyond the schema. Baseline 3 applies.

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?

The description names a concrete verb and resource — check follow relationships between one source account and up to 50 targets, including follow-back direction — which is distinct from the listing siblings like get_followers and get_following. It does not name those siblings explicitly, so an agent must infer the boundary from 'in one call'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is only implied: 'in one call' and 'up to 50' suggest this replaces many per-account lookups, and 'errors for handles that could not be looked up' hints at tolerance for bad input. There is no explicit when-to-use/when-not statement and no mention of an alternative single-target tool.

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

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