Skip to main content
Glama
XcrapCC

@xcrap/mcp

Official
by XcrapCC
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

Fetch many X posts at once

xcrap_bulk
Read-onlyIdempotent

Resolve up to 50 X (Twitter) post URLs or IDs in one call, with per-item failures so one dead link doesn't lose the batch. Use for lists or extracted IDs.

Instructions

Resolve up to 50 post URLs or ids in a single call.

This is the right tool whenever you have more than two or three links. One bulk call costs one request against a 10-per-5-minutes budget, while the same posts fetched individually cost one request each against a 60-per-minute budget — and bulk runs them concurrently, so it is several times faster.

Failures are per item, not per request: one dead link in a batch of fifty returns forty-nine posts and one error entry, so a single bad URL never loses the batch.

When to use this instead of the alternatives:

  • Use this for a list of links, a set of ids extracted from a document, or a batch job.

  • Use xcrap_get_tweet for a single post — bulk uses a cheaper, lighter source and returns slightly less detail per post (no media variants or entity offsets).

  • Use xcrap_get_thread for connected posts by one author; bulk does not know they are a thread.

Args:

  • urls (string[], required): 1-50 post URLs or numeric ids. Duplicates are removed by the server.

Returns markdown: a summary line of requested/succeeded/failed, then each post rendered in order, with an explicit error line for any that could not be resolved.

Errors: passing more than 50 URLs is rejected before any request is made — split the list into batches of 50.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlsYesPost URLs or numeric ids to resolve, 1-50 per call. Mixed forms are fine: ["https://x.com/jack/status/20", "20"].

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.0

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, but the description adds substantial behavioral context: per-item failure (one dead link doesn't lose the batch), concurrency, request-cost/budget comparison, duplicate removal, and server-side rejection of >50 URLs. These go well beyond what annotations convey and are crucial for correct invocation.

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 description is well-structured with clear sections (main purpose, usage context, alternatives, args, returns, errors) and every sentence contributes meaningful information. It is front-loaded with the primary purpose and a direct usage guideline, and there is no filler or redundancy.

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?

Given the tool's complexity—batch processing, partial failures, rate limits, and a markdown return format—the description covers all necessary aspects: what it does, when to use it, how failures behave, input constraints, and even the return format. There is no output schema, so the description appropriately explains the markdown structure. Nothing an agent needs to call 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 the single `urls` parameter already includes a detailed description covering mixed forms and 1-50 limit. The description adds the 'Duplicates are removed by the server' behavior and clarifies that numeric ids are accepted, providing extra semantic value beyond the schema alone. Slightly above the baseline of 3.

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 ('resolve'), resource ('post URLs or ids'), and a clear scope ('up to 50 in a single call'). It also distinguishes itself from siblings by naming xcrap_get_tweet and xcrap_get_thread explicitly, so an agent can tell exactly what this tool does and what it does not do.

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 says 'This is the right tool whenever you have more than two or three links' and provides clear when-to-use-this vs. when-to-use-alternatives: use xcrap_get_tweet for a single post and xcrap_get_thread for connected posts. This is unambiguous guidance with no room for inference.

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