What can you do with this server?

This MCP server provides offline access to TwitterAPI.io documentation for AI assistants, enabling instant lookup of 54 API endpoints, guides, and blog posts without internet access. Core Capabilities: * Search documentation - Full-text fuzzy search across all endpoints, guides, and blog posts with camelCase/underscore support and typo tolerance * Get endpoint details - Retrieve complete API documentation including HTTP methods, paths, parameters, cURL examples, and code snippets * Browse endpoints by category - List all 54 endpoints organized by 9 categories (user, tweet, community, webhook, stream, action, dm, list, trend) * Access guide pages - Fetch full content of documentation pages like pricing, authentication, QPS limits, filter rules, privacy policy, terms of service, and changelogs * Fetch content by URL - Retrieve content from specific TwitterAPI.io URLs using the offline snapshot with optional live fetching fallback * Get pricing information - Quick access to pricing tiers, credit costs per endpoint, and QPS rate limits * Get authentication guide - Comprehensive authentication setup with API key headers, base URLs, and code examples in cURL, Python, and JavaScript Key Features: * Offline-first operation with hybrid caching (memory + disk, 24-hour TTL) for optimal performance * Tool chaining support with suggested follow-up actions in search results * Instant retrieval without network latency

How do I use twitterapi-io-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@twitterapi-io-mcp search for rate limit information" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

de en es ja ko ru zh

twitterapi-io-mcp

by dorukardahan

Overview Schema Related Servers Score Discussions

JavaScript

twitterapi-io-mcp

Offline TwitterAPI.io documentation for Claude and AI assistants via MCP. 67 active endpoints (with full method/params/body), 32 guides, 24 blog posts. No API key needed.

npm version npm downloads Smithery GitHub stars License: MIT

# Quick install (Claude Code)
claude mcp add twitterapi-io -- npx -y twitterapi-io-mcp

What is this?

An MCP server that gives Claude, Cursor, VS Code Copilot, and other AI assistants instant, offline access to TwitterAPI.io documentation.

67 active API endpoints with full HTTP method, body/query parameters, cURL examples, and response schemas
32 guide pages covering pricing, authentication, rate limits, webhooks, streaming
24 blog posts with tutorials and use cases
All v2 write endpoints documented with login_cookies, proxy, and body params
All deprecated v1 endpoints removed — only current v2 endpoints remain
Zero API key required — everything is bundled locally

Unlike other Twitter MCP servers that proxy live API calls (and need your API key), this one ships a complete documentation snapshot. Your AI assistant reads it locally, instantly.

Recent Changes

v1.2.0: OpenAPI-first scraper rewrite — structured parameters with types, response schemas, eliminates Vercel checkpoint issues
v1.1.x: Added list_timeline + get_user_timeline, removed 7 deprecated V1 endpoints, security fixes (hono, ajv, express-rate-limit)
v1.0.23: Platform advisory — Twitter disabled since:/until: search operators. Use since_time:UNIX / until_time:UNIX instead
v1.0.22: Added 7 endpoints (get_space_detail, get_tweet_replies_v2, get_user_about, etc.)

See CHANGELOG.md for full history.

Disclaimer: Independent community project. Not affiliated with TwitterAPI.io.

Related MCP server: mcp-server-markdown

Installation

Previously published as twitterapi-docs-mcp? Just change the package name — everything else stays the same.

Requires: Node.js 18.18.0+

Claude Code (recommended)

# Add globally (all projects)
claude mcp add --scope user twitterapi-io -- npx -y twitterapi-io-mcp

# Or project-only
claude mcp add twitterapi-io -- npx -y twitterapi-io-mcp

# Verify
claude mcp list

Claude Desktop

Add to your config file:

macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
Linux: ~/.config/Claude/claude_desktop_config.json

{
  "mcpServers": {
    "twitterapi-io": {
      "command": "npx",
      "args": ["-y", "twitterapi-io-mcp"]
    }
  }
}

Cursor

Add to .cursor/mcp.json in your project root:

{
  "mcpServers": {
    "twitterapi-io": {
      "command": "npx",
      "args": ["-y", "twitterapi-io-mcp"]
    }
  }
}

VS Code / VS Code Insiders

Add to .vscode/mcp.json in your project root:

{
  "servers": {
    "twitterapi-io": {
      "command": "npx",
      "args": ["-y", "twitterapi-io-mcp"]
    }
  }
}

Windsurf

Add to ~/.codeium/windsurf/mcp_config.json:

{
  "mcpServers": {
    "twitterapi-io": {
      "command": "npx",
      "args": ["-y", "twitterapi-io-mcp"]
    }
  }
}

Docker

docker run -i --rm $(docker build -q .) 2>/dev/null

Or build from source:

git clone https://github.com/dorukardahan/twitterapi-io-mcp.git
cd twitterapi-io-mcp && npm install
node index.js

Available tools

Tool	Description	Best for
`search_twitterapi_docs`	Full-text search across all docs (fuzzy matching, typo-tolerant)	Finding endpoints, guides, or blog posts by keyword
`get_twitterapi_endpoint`	Get full endpoint documentation with params, examples, response schema	Deep dive into a specific API endpoint
`list_twitterapi_endpoints`	List endpoints, optionally filtered by category	Browsing what's available in a category
`get_twitterapi_guide`	Get guide pages (pricing, auth, rate limits, webhooks, etc.)	Understanding platform rules and setup
`get_twitterapi_url`	Fetch content by URL path or page key	When you have a direct link to docs
`get_twitterapi_pricing`	Quick pricing overview	Cost questions
`get_twitterapi_auth`	Quick authentication guide	Auth setup and API key usage

For AI assistants

If you're an AI assistant using this MCP server, here's a quick reference:

User wants...	Use this tool	Example
Find an endpoint	`search_twitterapi_docs`	`query: "advanced search"`
Endpoint details	`get_twitterapi_endpoint`	`endpoint_name: "tweet_advanced_search"`
List all endpoints	`list_twitterapi_endpoints`	`category: "user"` (optional)
Pricing info	`get_twitterapi_pricing`	No params needed
Auth guide	`get_twitterapi_auth`	No params needed
Any guide/page	`get_twitterapi_guide`	`guide_name: "qps_limits"`
Fetch by URL	`get_twitterapi_url`	`url: "pricing"`

Tips:

Search is fuzzy and typo-tolerant: "twet object" still finds results
Use max_results: 5 for focused results
All endpoints are current v2 — no deprecated endpoints remain

What can you ask?

Here are real prompts that work well with this MCP server:

"What are the rate limits for TwitterAPI.io?" — triggers get_twitterapi_guide
"Show me the tweet advanced search endpoint" — triggers get_twitterapi_endpoint
"How do I authenticate with the API?" — triggers get_twitterapi_auth
"What's the pricing?" — triggers get_twitterapi_pricing
"List all user-related endpoints" — triggers list_twitterapi_endpoints with category: "user"
"How do webhook filter rules work?" — triggers search_twitterapi_docs
"What write endpoints need login?" — triggers search_twitterapi_docs with query: "login_cookies"
"How do I upload media and create a tweet?" — triggers sequential get_twitterapi_endpoint calls

Category	Count	Endpoints
User	11	`get_user_by_username`, `get_user_timeline`, `get_user_last_tweets`, `get_user_followers`, `get_user_followings`, `get_user_mention`, `get_user_verified_followers`, `get_user_about`, `batch_get_user_by_userids`, `check_follow_relationship`, `search_user`
Tweet	8	`tweet_advanced_search`, `get_tweet_by_ids`, `get_tweet_reply`, `get_tweet_replies_v2`, `get_tweet_quote`, `get_tweet_retweeter`, `get_tweet_thread_context`, `get_article`
Action	8	`create_tweet_v2`, `delete_tweet_v2`, `like_tweet_v2`, `unlike_tweet_v2`, `retweet_tweet_v2`, `follow_user_v2`, `unfollow_user_v2`, `upload_media_v2`
Community	9	`get_community_by_id`, `get_community_members`, `get_community_moderators`, `get_community_tweets`, `get_all_community_tweets`, `create_community_v2`, `delete_community_v2`, `join_community_v2`, `leave_community_v2`
List	6	`get_list_followers`, `get_list_members`, `get_list_tweets`, `list_timeline`, `add_list_member`, `remove_list_member`
Profile	3	`update_avatar_v2`, `update_banner_v2`, `update_profile_v2`
Webhook	4	`add_webhook_rule`, `get_webhook_rules`, `update_webhook_rule`, `delete_webhook_rule`
Stream	3	`add_user_to_monitor_tweet`, `get_user_to_monitor_tweet`, `remove_user_to_monitor_tweet`
Auth	1	`user_login_v2`
DM	2	`get_dm_history`, `send_dm_v2`
Account	1	`get_my_info`
Other	2	`get_trends`, `get_space_detail`

Configuration

Environment Variable	Default	Description
`TWITTERAPI_MCP_DISK_CACHE`	`1` (on)	Set to `0` to disable disk caching

Troubleshooting

npx hangs or fails on first run

The first run downloads the package from npm. If it hangs, try:

npx -y twitterapi-io-mcp@latest

Or install globally: npm install -g twitterapi-io-mcp

"Node.js version not supported"

This server requires Node.js 18.18.0 or later. Check your version:

node --version

claude mcp add not recognized

Make sure Claude Code CLI is installed and up to date:

claude --version

Server starts but no tools appear

Restart your MCP client after adding the server config. Most clients (Claude Desktop, Cursor) need a restart to detect new MCP servers.

How it works

┌─────────────┐     MCP (stdio)      ┌──────────────────┐
│   Claude /   │ ◄──────────────────► │ twitterapi-io-mcp│
│  Cursor /    │                      │                  │
│  VS Code     │                      │  Bundled docs    │
└─────────────┘                      │  (67 endpoints)  │
                                     └──────────────────┘
                                       No network needed

Property	Value
Runtime	Node.js 18.18.0+ (ES Modules, no build step)
Protocol	MCP via stdio
Caching	Hybrid (memory + disk), 24h TTL
Search	N-gram tokenization with fuzzy matching

AI assistant calls an MCP tool (search, get endpoint, etc.)
Server searches the bundled documentation snapshot
Results return instantly with no network requests

Why I built this

I use TwitterAPI.io daily for my projects. Switching between my editor and their docs site got old fast. So I packaged the entire documentation into an MCP server. Now I ask Claude and get answers without leaving my terminal.

If you work with the Twitter/X API through TwitterAPI.io, this saves you the same context-switching. Install it, forget about it, and just ask.

Development

git clone https://github.com/dorukardahan/twitterapi-io-mcp.git
cd twitterapi-io-mcp
npm install
npm test        # Run tests (48 tests)
npm start       # Start server locally
npm run scrape  # Update docs snapshot from twitterapi.io

Not using MCP?

If your AI tool doesn't support MCP (like OpenClaw), use the skill version instead — a single markdown file with all 67 active endpoints:

👉 twitterapi-io-skill — works with OpenClaw, Claude, GPT, Gemini, and any LLM.

Contributing

PRs welcome! Fork the repo, create a branch, make your changes, and open a pull request. Bug reports and feature requests go to GitHub Issues.

License

MIT

Acknowledgments

TwitterAPI.io for the API service
Anthropic for the Model Context Protocol
MCP TypeScript SDK

Tool Definition Quality

A4.4/5.0

Tool DescriptionsA

Average 4.3/5 across 7 of 7 tools scored.

Server CoherenceA

Disambiguation5/5

Each tool has a clearly distinct purpose: authentication, specific endpoint docs, page content, pricing, URL fetching, listing endpoints, and searching docs. No overlap in functionality.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern with underscore (get_, list_, search_) and include 'twitterapi' for context. No mixing of conventions.

Tool Count5/5

7 tools is well-scoped for a documentation-focused server. Each tool provides a necessary function without redundancy, and the count is appropriate for the domain.

Completeness4/5

The tool set covers core documentation needs: auth, endpoint details, pricing, search, and listing. Minor gaps like error codes or changelog, but the surface is largely complete.

Available Tools

7 tools

get_twitterapi_authA

Get TwitterAPI.io authentication guide: API key usage, headers, code examples.

USE THIS WHEN: You need to set up authentication or see request examples. RETURNS: API key header format, base URL, cURL/Python/JavaScript examples.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`header`	Yes
`base_url`	Yes
`examples`	No
`markdown`	Yes
`dashboard_url`	No

Tool Definition Quality

A4.5/5.0

Behavior4/5

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

No annotations provided, so description carries full burden. It discloses the return content (API key header format, base URL, code examples) which is the primary behavior. It does not mention side effects or safety, but as a read-only guide retrieval, the return disclosure is sufficient.

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?

Very concise and well-structured: a one-line summary, then explicit 'USE THIS WHEN' and 'RETURNS' sections. Every sentence adds value with no 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?

For a zero-parameter tool with an output schema, the description fully covers the return value content (header format, base URL, code examples) and usage context. It is complete given the tool's simplicity.

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?

No parameters exist (0 params), so schema coverage is 100%. Baseline score of 4 applies; description adds no parameter info because none are needed.

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 clearly states 'Get TwitterAPI.io authentication guide' with specific focus on API key usage, headers, and code examples. It distinguishes itself from siblings like get_twitterapi_endpoint by being auth-specific.

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?

The 'USE THIS WHEN' section explicitly states when to use the tool: 'set up authentication or see request examples.' No exclusions or alternatives are mentioned, but the context is clear.

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

get_twitterapi_endpointA

Get complete documentation for a specific TwitterAPI.io endpoint.

USE THIS WHEN: You know the exact endpoint name (e.g., from search results). RETURNS: Full details including path, parameters, cURL example, and code snippets.

Common endpoints:

get_user_info, get_user_followers, get_user_following
tweet_advanced_search, get_tweet_by_id
add_webhook_rule, get_webhook_rules

ParametersJSON Schema

Name	Required	Description	Default
`endpoint_name`	Yes	Exact endpoint name (use underscores). Examples: 'get_user_info', 'tweet_advanced_search', 'add_webhook_rule'

Output Schema

ParametersJSON Schema

Name	Required	Description
`path`	No
`title`	No
`cached`	No
`method`	No
`doc_url`	No
`full_url`	No
`markdown`	Yes
`raw_text`	No
`parameters`	No
`description`	No
`curl_example`	No
`code_snippets`	No
`endpoint_name`	Yes

Tool Definition Quality

A4.5/5.0

Behavior4/5

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

Description details return values: 'Full details including path, parameters, cURL example, and code snippets.' No annotations are provided, so the description bears full burden and does so clearly.

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?

Concise and front-loaded: purpose in first sentence, usage guideline in second, and a list of examples. No unnecessary words.

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?

Tool is simple with one parameter and an output schema present. Description covers what the tool does, when to use it, and what it returns, fully meeting the needs.

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%, baseline is 3. Description adds value by providing examples and usage note for the parameter, going beyond the schema's description.

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?

Description clearly states 'Get complete documentation for a specific TwitterAPI.io endpoint' with a specific verb and resource, and distinguishes from siblings by focusing on single endpoints.

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?

Explicitly says 'USE THIS WHEN: You know the exact endpoint name (e.g., from search results),' providing clear context. Does not explicitly mention alternatives, but sibling tools like search_twitterapi_docs imply when not to use.

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

get_twitterapi_guideA

Get a TwitterAPI.io page from the offline snapshot by page key.

USE THIS WHEN: You need the full content of a specific page (guides, docs, policies, contact, etc.). TIP: Use search_twitterapi_docs if you don't know the page key.

RETURNS: Full guide content with headers, paragraphs, and code examples.

ParametersJSON Schema

Name	Required	Description	Default
`guide_name`	Yes	Page key (from data/pages). Examples: pricing, qps_limits, privacy, contact, introduction, authentication.

Output Schema

ParametersJSON Schema

Name	Required	Description
`url`	No
`title`	No
`headers`	No
`markdown`	Yes
`raw_text`	No
`guide_name`	Yes
`list_items`	No
`paragraphs`	No
`description`	No
`code_snippets`	No

Tool Definition Quality

A4/5.0

Behavior2/5

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

No annotations provided, so description must cover behavioral traits. It mentions 'offline snapshot' but does not explain staleness, authentication needs, or read-only nature. Lacks depth.

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?

Three sentences: action, usage guidance, return info. Front-loaded, no wasted words. Efficiently conveys essential information.

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?

Given simple tool with one parameter, schema covers all options, output schema exists. Description mentions return content format. Minor lack of clarity on 'offline snapshot' implications.

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 has 100% coverage with enum and description, so baseline is 3. The description adds example values but no additional semantics beyond the schema.

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 clearly states it retrieves a TwitterAPI.io page from an offline snapshot by page key, using specific verb and resource. It distinguishes from sibling by advising use of search_twitterapi_docs for unknown keys.

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 states when to use: for full content of a specific page. Provides alternative tool when page key is unknown, offering clear context.

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

get_twitterapi_pricingA

Get TwitterAPI.io pricing information: credit system, endpoint costs, QPS limits.

USE THIS WHEN: You need to know API costs, credit calculations, or rate limits. RETURNS: Pricing tiers, credit costs per endpoint, QPS limits by balance level.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`costs`	No
`notes`	No
`markdown`	Yes
`qps_limits`	No
`minimum_charge`	No
`credits_per_usd`	No

Tool Definition Quality

A4.5/5.0

Behavior4/5

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

No annotations provided, so description carries full burden. It discloses what the tool returns (pricing tiers, credit costs per endpoint, QPS limits). It doesn't specify if any authentication is needed, but for a read-only info tool, this is sufficient.

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?

Extremely concise: two sentences plus a 'RETURNS:' line. Front-loaded with purpose and usage guidance. No wasted words.

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 it has an output schema (not shown but indicated), the description does not need to fully detail return values. It lists key items: pricing tiers, credit costs, QPS limits. For a simple no-parameter tool, it 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?

No parameters exist (0 params, 100% schema coverage). Baseline is 4. The description adds meaning by explaining what the tool returns, but no parameter details needed.

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 clearly states it provides 'pricing information: credit system, endpoint costs, QPS limits.' It also includes a 'RETURNS:' section listing specific outputs. This distinguishes it from sibling tools that deal with authentication, endpoints, guides, and documentation.

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?

Explicit 'USE THIS WHEN:' section tells when to use the tool: 'need to know API costs, credit calculations, or rate limits.' No explicit when-not or alternatives, but the context is clear given the sibling list.

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

get_twitterapi_urlA

Fetch a TwitterAPI.io or docs.twitterapi.io URL.

USE THIS WHEN: You have a specific link and want its full content. RETURNS: Parsed content from the offline snapshot. If not found, you can set fetch_live=true (restricted to twitterapi.io/docs.twitterapi.io).

ParametersJSON Schema

Name	Required	Description	Default
`url`	Yes	URL to fetch. Examples: https://twitterapi.io/privacy, /pricing, docs.twitterapi.io/introduction
`fetch_live`	No	If true and the URL is missing from the offline snapshot, fetch it live over HTTPS (allowed hosts only).

Output Schema

ParametersJSON Schema

Name	Required	Description
`url`	Yes
`kind`	Yes
`name`	Yes
`title`	No
`source`	Yes
`markdown`	Yes
`description`	No

Tool Definition Quality

A4.2/5.0

Behavior3/5

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

No annotations are provided, so the description must disclose behavioral traits. It states that content comes from an offline snapshot and that live fetching is possible but restricted to allowed hosts. However, it does not detail error handling, authentication, or what happens if live fetch fails. Adequate but not fully transparent.

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 extremely concise: two sentences plus a 'USE THIS WHEN' and 'RETURNS' section. Every sentence is purposeful, front-loaded, and wastes no words.

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?

Given the tool's low complexity (2 params, 1 required, output schema exists), the description provides sufficient context for basic usage. It covers purpose, when to use, and parameter details. However, it could mention more about the output or potential errors, but the output schema likely covers that.

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?

Input schema coverage is 100%, so baseline is 3. The description adds value by providing examples for the 'url' parameter and clarifying the behavior of 'fetch_live' (restricted to allowed hosts). This helps the agent understand usage beyond the schema.

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 clearly states the verb 'Fetch' and the resource 'URL' with a specific context of 'TwitterAPI.io or docs.twitterapi.io'. It distinguishes from sibling tools like get_twitterapi_endpoint or search_twitterapi_docs, as this tool is for fetching full content of a specific link.

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?

The description explicitly provides a 'USE THIS WHEN' section: 'You have a specific link and want its full content.' It also hints at alternatives (fetch_live for missing content) but does not explicitly mention when not to use it or compare with siblings. Clear positive guidance, but lacking explicit exclusion criteria.

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

list_twitterapi_endpointsA

List all TwitterAPI.io API endpoints organized by category.

USE THIS WHEN: You need to browse available endpoints or find endpoints by category. CATEGORIES: user, tweet, community, webhook, stream, action, dm, list, trend

RETURNS: Endpoint names with HTTP method and path for each category.

ParametersJSON Schema

Name	Required	Description	Default
`category`	No	Optional filter: user, tweet, community, webhook, stream, action, dm, list, trend, other

Output Schema

ParametersJSON Schema

Name	Required	Description
`total`	Yes	Number of endpoints returned (after optional category filter).
`category`	No
`markdown`	Yes
`endpoints`	Yes
`total_all`	No	Total endpoints in the snapshot (before filtering).

Tool Definition Quality

A4/5.0

Behavior3/5

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

No annotations are provided, so the description must convey behavioral traits. It indicates the tool returns endpoint names with HTTP method and path, which is expected for a listing tool. However, it does not mention any side effects, rate limits, or authentication requirements, though these may be less critical for a read-only listing.

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 concise and well-structured with clear sections (USE THIS WHEN, CATEGORIES, RETURNS). Every sentence adds value, and the length is appropriate for the tool's simplicity.

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?

The tool is a listing tool with one optional parameter and an output schema. The description covers usage guidance and return values. It could improve by mentioning that for detail on a specific endpoint, one should use get_twitterapi_endpoint, but overall it is adequately complete given the sibling tools.

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?

The input schema has one optional parameter with an enum. Schema description coverage is 100% (the schema description lists all values). The tool description adds a list of categories that mostly matches the enum, but does not add significant meaning beyond the schema. The description implies the parameter is for filtering, which aligns with the schema.

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 clearly states it lists all endpoints organized by category. It distinguishes from sibling tools like get_twitterapi_endpoint (which retrieves a single endpoint) and search_twitterapi_docs (which searches documentation).

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?

The description includes a 'USE THIS WHEN' section explicitly stating when to use the tool: to browse available endpoints or find endpoints by category. It does not explicitly mention when not to use, but the context implies that for specific endpoint details one should use get_twitterapi_endpoint.

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

search_twitterapi_docsA

Search TwitterAPI.io documentation: API endpoints, guides (pricing, rate limits, filter rules), and blog posts.

USE THIS WHEN: You need to find information across the entire documentation. RETURNS: Ranked results with endpoint paths, descriptions, and relevance scores.

Examples:

"advanced search" → finds tweet search endpoints
"rate limit" → finds QPS limits and pricing info
"webhook" → finds webhook setup endpoints
"getUserInfo" → finds user info endpoints (supports camelCase)

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes	Search query (1-500 chars). Use English keywords like: 'search', 'user', 'tweet', 'webhook', 'pricing', 'rate limit'. Supports camelCase and underscore formats.
`max_results`	No	Number of results to return. Use higher values (15-20) for comprehensive research, lower values (3-5) for quick lookups.

Output Schema

ParametersJSON Schema

Name	Required	Description
`query`	Yes	Normalized (trimmed) search query.
`cached`	No	Whether this response was served from cache.
`counts`	No
`results`	Yes
`markdown`	Yes	Human-readable markdown rendering of the results.
`max_results`	Yes	Applied max results (1-20).

Tool Definition Quality

A4.6/5.0

Behavior4/5

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

No annotations provided, so the description carries full burden. It details that the tool returns 'Ranked results with endpoint paths, descriptions, and relevance scores' and supports camelCase/underscore. It could mention rate limits or authentication, but the read-only search nature is implied.

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 concise and well-structured: a brief statement, 'USE THIS WHEN', 'RETURNS', and examples. Every sentence serves a purpose, and the format is front-loaded with essential information.

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 simplicity (2 parameters, no nested objects), the description fully covers purpose, usage, return value, and examples. It integrates well with sibling tools and provides enough context for an AI agent to select and invoke correctly.

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

Parameters5/5

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

Input schema has 100% coverage with good descriptions. The description adds value by providing example queries, specifying English keywords, and offering usage guidance for max_results (e.g., 'higher values for comprehensive research, lower for quick lookups').

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 clearly states it searches TwitterAPI.io documentation for endpoints, guides, and blog posts. It distinguishes from sibling tools (e.g., get_twitterapi_endpoint, get_twitterapi_guide) by targeting across the entire documentation, with examples like 'advanced search' and 'rate limit'.

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?

The description explicitly includes 'USE THIS WHEN: You need to find information across the entire documentation,' providing clear context. It does not explicitly mention when not to use it or alternatives, but the sibling tool list implies those for specific lookups.

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

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

license - permissive license

quality

maintenance

How are these scores calculated?

Maintenance

5dRelease cycle

45Releases (12mo)

Commit activity

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Tools

Related MCP Connectors

Context Awesome A
io.github.bh-rat
MCP server for accessing curated awesome list documentation
Documentation Access Research & Data
2259
OrchestKit Docs MCP A
io.github.yonatangross
Read-only MCP server for the OrchestKit docs: full-text search + Markdown fetch. No auth.
Documentation Access Search
23186
forkast-mcp-docs A
io.github.ForkastPredict
MCP server for querying Forkast documentation
Documentation Access Search Developer Tools
42
mcp A
ai.llmse
Public MCP server for the LLM Search Engine
Search RAG Systems Developer Tools
102

Related MCP Servers

devdocs-mcp
Developer Tools Documentation Access Knowledge & Memory
madhan-g-p
A
license
Not graded
quality
D
maintenance
An MCP server that provides version-pinned, deterministic documentation sourced from DevDocs.io to AI assistants (Claude, RooCode, Cline, Copilot etc.) and also via offline mode. Not via Scraping! But using the supported downloading option from devdocs.
Updated 4 months ago (2026-05-10 07:42 UTC)
38
13
MIT
mcp-server-markdown
Developer Tools Documentation Access File Systems
ofershap
A
license
A
quality
D
maintenance
MCP server for markdown files — search, extract sections, list headings, find code blocks across docs.
Updated 23 days ago (2026-08-10 07:38 UTC)
6
67
5
MIT
MkDocs MCP Server
Search Documentation Access RAG Systems
ehsanmsb
A
license
Not graded
quality
A
maintenance
A generic, configurable MCP server that makes any MkDocs documentation site searchable and explorable from MCP clients.
Updated 2 months ago (2026-06-21 09:37 UTC)
MIT
wikijs-mcp
Documentation Access Content Management Systems
ValoriaTechnologia
F
license
Not graded
quality
C
maintenance
MCP server to search and read documentation pages from a WikiJS instance via its GraphQL API.
Updated 6 months ago (2026-03-16 14:43 UTC)

View all related MCP servers

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/dorukardahan/twitterapi-io-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

twitterapi-io-mcp

What is this?

Recent Changes

Installation

Claude Code (recommended)

Claude Desktop

Cursor

VS Code / VS Code Insiders

Windsurf

Docker

Available tools

For AI assistants

What can you ask?

Configuration

Troubleshooting

How it works

Why I built this

Development

Not using MCP?

Links

Contributing

License

Acknowledgments

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Maintenance

Resources

Looking for Admin?

Tools

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API