Enhanced Grok Search MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation2/5
Multiple tools have overlapping purposes that could cause confusion. grok_search, grok_web_search, and grok_news_search all perform web searches with similar comprehensive analysis modes, making it difficult for an agent to choose the right tool. Only grok_twitter and health_check have clearly distinct functions.
Naming Consistency4/5
The naming follows a consistent snake_case pattern with a 'grok_' prefix for most tools, which is predictable and readable. The only deviation is health_check, which lacks the prefix but maintains the same naming style, keeping the set mostly consistent.
Tool Count3/5
With 5 tools, the count is reasonable for a search-focused server, but it feels borderline due to redundancy. The set could be streamlined without losing functionality, as multiple tools cover similar search domains, making the number slightly heavy for the apparent scope.
Completeness3/5
The server covers news, web, and Twitter search with health monitoring, but there are notable gaps. For a search domain, missing tools for filtering, saving results, or handling advanced queries limit agent workflows. The surface is functional but incomplete for comprehensive search operations.
Average 3.1/5 across 5 of 5 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions 'comprehensive mode analyzes social media trends and sentiment' which adds some behavioral context, but doesn't address critical aspects like rate limits, authentication requirements, data freshness, or what happens when no results are found. The description is insufficient for a search tool with 6 parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with two sentences. The first sentence states the core functionality, and the second adds important context about the comprehensive mode. However, the second sentence could be more tightly integrated with the first for better flow.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with 6 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what the tool returns (tweet objects, analysis results, error conditions), doesn't mention pagination or result format, and provides minimal behavioral context. The comprehensive mode mention helps but doesn't compensate for the overall gaps.
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 100%, so the schema already documents all 6 parameters thoroughly. The description mentions 'optionally filtered by specific handles' and 'comprehensive mode analyzes social media trends and sentiment', which adds minor context about the 'handles' and 'analysis_mode' parameters, but doesn't provide significant value beyond what's already in the schema descriptions.
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 clearly states the tool's purpose: 'Search Twitter/X posts using Grok's X search capabilities' with optional filtering. It specifies the verb ('search') and resource ('Twitter/X posts'), but doesn't explicitly differentiate from sibling tools like 'grok_search' or 'grok_web_search' beyond mentioning 'Twitter/X' specifically.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'comprehensive mode analyzes social media trends and sentiment' which implies some usage context, but provides no explicit guidance on when to use this tool versus alternatives like 'grok_search' or 'grok_web_search'. There's no mention of prerequisites, limitations, or comparative scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'comprehensive analysis mode for detailed insights,' which hints at enhanced output, but doesn't describe what the tool returns (e.g., search results format, error handling, rate limits, or authentication needs). For a search tool with no annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the core purpose in the first sentence. The second sentence adds useful detail about analysis mode without redundancy. Both sentences earn their place, making it efficient, though it could be slightly more structured by explicitly listing key features.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters, no output schema, no annotations), the description is incomplete. It lacks details on return values, error conditions, and behavioral traits like rate limits or permissions. Without annotations or output schema, the description should compensate more to guide effective use, but it falls short.
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 100%, so the schema fully documents all 5 parameters. The description adds minimal value beyond the schema: it mentions 'comprehensive analysis mode' which aligns with the 'analysis_mode' parameter's enum, but doesn't provide additional context like use cases or examples. Baseline 3 is appropriate as the schema does the heavy lifting.
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 clearly states the tool's purpose: 'Search general web content using Grok.' It specifies the verb ('Search') and resource ('general web content'), and mentions 'comprehensive analysis mode for detailed insights' to differentiate it from basic search. However, it doesn't explicitly distinguish it from sibling tools like 'grok_news_search' or 'grok_search', which likely have overlapping functions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions 'comprehensive analysis mode' but doesn't explain when to choose this over basic mode or how it compares to sibling tools like 'grok_news_search' or 'grok_search'. There are no explicit when/when-not statements or named alternatives, leaving usage context unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions that 'comprehensive mode provides timeline analysis, direct quotes, and multiple perspectives,' which adds some context about output behavior. However, it lacks critical details such as rate limits, authentication needs, data freshness, or what happens with invalid parameters, leaving significant gaps for a tool with 5 parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with two sentences that are front-loaded with the core purpose. The second sentence efficiently elaborates on the 'comprehensive mode' without redundancy. However, it could be slightly more structured by explicitly separating usage contexts.
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?
Given 5 parameters, no annotations, and no output schema, the description is moderately complete. It covers the tool's purpose and hints at behavioral aspects, but lacks details on output format, error handling, or integration with sibling tools. For a search tool with multiple parameters and no structured output documentation, this leaves room for improvement.
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 100%, so the schema fully documents all 5 parameters. The description adds minimal value by hinting at the 'comprehensive' mode's features, but doesn't provide additional semantic context beyond what's in the schema (e.g., explaining how 'query' differs from general search or the impact of date ranges). Baseline 3 is appropriate as the schema does the heavy lifting.
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 clearly states the tool's purpose as 'Search for recent news using Grok' with a specific verb ('Search') and resource ('recent news'), distinguishing it from general search tools. However, it doesn't explicitly differentiate from sibling tools like 'grok_search' or 'grok_web_search' beyond the 'news' focus.
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 when to use this tool by mentioning 'recent news' and 'comprehensive mode' for detailed analysis, suggesting it's for news-specific searches with optional in-depth analysis. However, it doesn't provide explicit guidance on when to choose this over alternatives like 'grok_search' or 'grok_twitter', nor does it mention exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'AI-powered search capabilities' and analysis features like 'timelines, quotes, and multiple perspectives,' but lacks details on rate limits, authentication needs, error handling, or response format. For a search tool with 6 parameters and no annotations, this is a significant gap in behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, with two sentences that efficiently state the tool's purpose and capabilities. Every sentence adds value without waste, making it appropriately sized for the tool's complexity.
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?
Given the tool's moderate complexity (6 parameters, no output schema, no annotations), the description is adequate but incomplete. It covers the basic purpose and analysis modes but lacks details on behavioral traits, usage differentiation from siblings, and output expectations. Without annotations or output schema, more context would improve completeness for effective agent use.
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 100%, so the schema already documents all parameters thoroughly. The description adds some context by mentioning 'comprehensive analysis with timelines, quotes, and multiple perspectives,' which relates to the 'analysis_mode' parameter, but doesn't provide additional semantic meaning beyond what the schema specifies. Baseline 3 is appropriate as the schema does the heavy lifting.
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 clearly states the tool's purpose: 'Search the web using Grok's AI-powered search capabilities.' It specifies the verb ('search') and resource ('the web'), and mentions AI-powered capabilities. However, it doesn't explicitly differentiate from siblings like 'grok_web_search' or 'grok_news_search' beyond mentioning search types, which limits differentiation.
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 usage by mentioning support for 'basic search results and comprehensive analysis,' but it doesn't provide explicit guidance on when to use this tool versus siblings like 'grok_news_search' or 'grok_web_search.' No alternatives or exclusions are stated, leaving usage context implied rather than clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions checking 'health status' and 'API connectivity' but doesn't disclose behavioral traits like what specific metrics are returned, whether it performs active tests or passive checks, expected response format, or potential side effects. The description is functional but lacks operational transparency needed for informed tool selection.
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, efficient sentence that clearly communicates the core purpose without any wasted words. It's appropriately sized for a simple health check tool and front-loads the essential information. Every word earns its place in conveying what the tool does.
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?
Given the tool's simplicity (0 parameters, no output schema), the description is reasonably complete for understanding its basic purpose. However, without annotations or output schema, it doesn't provide enough information about what health data is returned or how to interpret results. For a diagnostic tool, users need more context about expected outputs and success/failure indicators.
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 0 parameters with 100% schema description coverage, so the schema already fully documents the parameter situation. The description appropriately doesn't discuss parameters since none exist. It focuses correctly on the tool's purpose rather than attempting to describe non-existent inputs.
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 clearly states the tool's purpose with a specific verb ('Check') and resource ('health status of the Grok Search MCP server and API connectivity'). It distinguishes itself from sibling tools like grok_search or grok_web_search by focusing on system health rather than data retrieval. However, it doesn't explicitly differentiate from all siblings (e.g., grok_news_search also involves checking/searching).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention scenarios like troubleshooting connectivity issues, verifying server availability before other operations, or whether it should be used proactively. With sibling tools focused on search functionality, there's no explicit comparison or exclusion criteria provided.
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:

[![grok-search-mcp MCP server](https://glama.ai/mcp/servers/stat-guy/grok-search-mcp/badges/card.svg)](https://glama.ai/mcp/servers/stat-guy/grok-search-mcp)

Score Badge

Copy to your README.md:

[![grok-search-mcp MCP server](https://glama.ai/mcp/servers/stat-guy/grok-search-mcp/badges/score.svg)](https://glama.ai/mcp/servers/stat-guy/grok-search-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/stat-guy/grok-search-mcp'

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