twscrape-twitter-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.3
Disambiguation5/5
Each tool targets a distinct aspect of X data: auth status, individual tweets, user profiles, threads, replies, quotes, timelines, and search. Even though read_thread and read_replies both involve replies, their scopes are clearly differentiated.
Naming Consistency4/5
The naming is mostly consistent with snake_case and a read_* prefix for the data access tools, but auth_status, user_profile, user_timeline, and search follow a different pattern. This minor inconsistency does not hinder usability.
Tool Count5/5
Eight tools provide a well-scoped coverage for a read-only Twitter client. Each tool serves a clear purpose and the count is within the ideal range for a focused server.
Completeness4/5
The tool set covers the core read workflows: tweets, profiles, threads, replies, quotes, timelines, and search. Minor gaps exist, such as no ability to fetch a user's followers/following or to paginate through large result sets, but these are reasonable for the stated purpose.
Average 4.2/5 across 8 of 8 tools scored. Lowest: 3.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 30 commits in the last 12 weeks
- Last stable release on June 28, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the read-only and external nature are covered. The description adds the markdown output format, which is useful. However, it does not disclose other behaviors like pagination, rate limits, or how the limit parameter affects results. With annotations present, this is acceptable but not rich.
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 a single, focused sentence that front-loads the action and output format. Every word earns its place, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and has an output schema, so the description need not explain return values. However, it lacks guidance on parameter semantics (particularly limit) and usage context. Given the low schema coverage, the description partially compensates but leaves gaps that the agent must infer from the name and siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters. It implies url_or_id refers to the X post, but does not explicitly describe the accepted format (URL vs ID) or the meaning of 'limit'. The parameter names and constraints exist in the schema, but the description adds minimal semantic value beyond the obvious.
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 uses a specific verb 'Read' with a clear resource ('replies to an X post') and output format ('as markdown'). It distinguishes from siblings like read_tweet (single post) and read_thread (thread), making the purpose unambiguous.
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 implied by the tool name and description ('Read the replies') but no explicit guidance is given about when to use this versus alternatives like read_quotes or user_timeline. The sibling names provide context, but the description does not mention them or exclude other scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, so the safety profile is known. The description adds that output is 'clean markdown', which informs the agent about response formatting. This adds value beyond annotations without contradicting them.
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, direct and free of filler. The action and key input are front-loaded.
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 single-parameter read tool with readOnly and openWorld annotations plus an output schema, the description provides sufficient context: what it does, how to specify input, and what output to expect. It doesn't cover edge cases, but these are less critical given the tool's simplicity.
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 no property descriptions, so the description's note that the parameter accepts a URL or numeric id adds necessary semantics. However, it doesn't elaborate on formats or edge cases, leaving some ambiguity.
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 tool reads a single X post, specifying input as URL or numeric id, which distinguishes it from sibling tools like read_thread or read_replies that handle conversations or contextual posts.
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?
The description implies the tool is for individual posts but does not explicitly state when to prefer it over siblings like read_thread or read_replies. It provides context ('single') but lacks explicit alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description discloses the output format (markdown) and the structural components returned (root, self-thread, top replies). It also reveals a convenient behavior: any tweet in the thread can serve as the input. This adds meaningful context without contradicting annotations.
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 two sentences long with no filler. It front-loads the primary purpose, then gives a practical input tip. Every word contributes to understanding the tool.
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 an output schema present and read-only annotations, the description covers the core behavior well: what is read, in what format, and how to specify the thread. It doesn't explain how max_replies affects 'top replies' or timing behavior, but the schema defaults and output schema reduce the need for that detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should compensate. It only hints at the meaning of url_or_id ('Pass any tweet in the thread') but provides no explanation for max_replies or include_replies. Even though the parameter names are somewhat self-explanatory, the description fails to add value beyond what the schema already states.
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 identifies the tool's purpose with a specific verb ('Read') and resource ('full X thread as markdown'). It explicitly lists the thread components (root post, author's self-thread, top replies), making it distinct from sibling tools like read_tweet or read_replies.
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 phrase 'Pass any tweet in the thread' gives concrete guidance on how to invoke the tool. While it doesn't explicitly contrast with alternatives, the description's emphasis on 'full thread' and 'top replies' implies it is intended for thread-level reading rather than single-tweet or replies-only use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the agent knows it's safe. The description adds valuable behavioral details: returns markdown, newest-first ordering, handle normalization, and include_replies behavior. These go beyond what annotations provide, though it could mention pagination or error conditions.
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 two sentences, front-loaded with the core purpose, and adds no fluff. Every sentence contributes useful information, making it highly concise and readable.
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 simple read tool with an output schema and readOnly annotation, the description covers the essential usage, input flexibility, and return format. It lacks details on pagination or edge cases, but these are likely in the output schema or not critical for basic invocation.
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 0%, so the description must compensate. It explains the username parameter (handle with/without @) and include_replies, but does not mention the limit parameter or its default/max behavior. The limit is somewhat self-evident from the schema, but the description doesn't fully cover all parameters.
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 tool reads a user's recent posts as markdown, newest first. The verb 'Read' plus the resource 'user's recent posts' is specific, and the format/order details distinguish it from siblings like read_tweet or user_profile.
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 gives clear context for using this tool (reading a user's timeline) and includes practical usage instructions for the username format (with or without @) and the include_replies parameter. It doesn't explicitly mention when not to use it, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true. The description adds a valuable behavioral guarantee ('without exposing cookies') that is not covered by annotations. No contradiction.
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 a single, front-loaded sentence with no wasted words. Every word adds meaning.
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 parameters and an output schema present, the description is complete for this simple check tool. The sibling context further clarifies its distinct purpose.
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?
The tool has zero parameters and an empty input schema. The baseline for zero-param tools is 4; the description correctly avoids unnecessary parameter details.
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 uses a specific verb ('Check') with a clear resource ('active X session') and scope ('this server'). It clearly differentiates from sibling tools which all focus on reading social media content.
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?
The description implies the tool is used for verifying server auth status but does not explicitly state when to use it or mention alternatives. No exclusions or context are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, but the description adds important behavioral context: 'best-effort' and 'coverage is partial, X does not expose a complete quotes endpoint.' This goes beyond the structured annotations and provides critical expectations about data completeness.
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 concise sentences front-load the purpose and immediately follow with the key limitation. No filler or redundant information, every sentence earns its place.
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, the output schema, and annotations, the description covers the essential aspects: what it does, how it does it, and its limitations. No critical behavioral detail is missing for a read-only, best-effort quote retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not explain what url_or_id or limit mean. While parameter names are intuitive, the description fails to compensate for the lack of schema documentation, leaving the agent without explicit guidance on usage constraints like limit's default/maximum.
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 states a specific verb ('Read') and resource ('quote-tweets of an X post'), and distinguishes from siblings like read_replies and read_tweet. It also mentions the method via search:quoted_tweet_id, making the purpose unambiguous.
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 clearly indicates this tool is for quote-tweets, which differentiates it from reading a tweet or replies. However, it does not explicitly mention when not to use it or point to alternatives (e.g., 'use read_replies for replies'), so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the description is not burdened with safety disclosure. It adds valuable behavioral detail: the return type (markdown), product filter options, and advanced query operator syntax, which go beyond the structured annotations.
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 front-loaded: the main function is stated in the first sentence, followed by a compact list of query options and examples. Every sentence earns its place, and no unnecessary filler exists.
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 an output schema present, the description does not need to explain return value structure. It provides enough operational guidance for a search tool with moderate complexity, including product choices and query syntax. It could mention pagination or limit behavior, but the schema and examples cover the essentials.
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?
The input schema has 0% description coverage, so the tool description must compensate. It successfully clarifies the 'query' parameter through operator examples and explains the 'product' enum values. The 'limit' parameter is not mentioned, but its default, minimum, and maximum are already fully specified in the schema, so no additional semantics 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 the action ('Search X') and the resource ('posts'), and specifies the output format ('as markdown'). This distinguishes it from sibling tools like read_tweet or user_timeline, which target specific tweets or timelines.
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 gives concrete usage context by listing product values and example X operators, making it clear how to construct queries. It does not explicitly state when not to use the tool or name alternative tools, but the sibling context makes the appropriate use apparent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description reinforces this with 'Read'. It adds valuable behavior beyond annotations by specifying the return format ('clean markdown') and the parameter flexibility (with or without @). This is more than the baseline requirement given the existing annotations.
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 short sentences, front-loaded with the core purpose, no wasted words. Every phrase adds value, including the return format and handle guidance.
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 has only one parameter, clear annotations, an output schema, and a low complexity, the description fully covers the essentials: what it does, how to provide input, and what format to expect. No critical gaps remain.
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?
The schema has 0% description coverage, so the description must compensate. It does so by clarifying that 'username' means the X handle and that it may include a leading @. Though brief, this fully covers the single parameter's meaning and format.
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 ('Read') and resource ('X user's profile'), and distinguishes this tool from siblings like read_tweet and user_timeline by focusing specifically on the profile rather than posts or timelines. The handle-based identifier is clearly specified.
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 makes the usage context clear: you use this tool when you need a user's profile by handle. It also provides input formatting guidance (optional leading @). It does not explicitly name alternatives or exclusions, but the context is unambiguous enough for an AI agent to select correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![twscrape-twitter-mcp MCP server](https://glama.ai/mcp/servers/jsilets/twscrape-twitter-mcp/badges/card.svg)](https://glama.ai/mcp/servers/jsilets/twscrape-twitter-mcp)

Score Badge

Copy to your README.md:

[![twscrape-twitter-mcp MCP server](https://glama.ai/mcp/servers/jsilets/twscrape-twitter-mcp/badges/score.svg)](https://glama.ai/mcp/servers/jsilets/twscrape-twitter-mcp)

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/jsilets/twscrape-twitter-mcp'

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