Pollinations Think MCP Server
Provides advanced strategic thinking and analysis capabilities using OpenAI reasoning models through the Pollinations AI API, with support for multi-cycle analysis, contradiction detection, and synthesis.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@Pollinations Think MCP Serveranalyze the pros and cons of remote work for tech companies"
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.
π§ Pollinations Think MCP Server
An advanced Model Context Protocol (MCP) server that provides sophisticated thinking and analysis capabilities using the Pollinations AI API with DeepSeek reasoning models.
π Features
π― Advanced Strategic Thinking: Multi-cycle analysis with contradiction detection and synthesis
π Flexible Model Support: DeepSeek reasoning, OpenAI reasoning, and other advanced models
π‘οΈ Robust Error Handling: Comprehensive retry logic and graceful degradation
βοΈ Configurable Parameters: Customizable thinking cycles, timeouts, and model selection
π Health Monitoring: Built-in health checks and status monitoring
βοΈ Cloud Deployment Ready: Optimized for Smithery.ai deployment to resolve network issues
Related MCP server: Think Strategies
π οΈ Available Tools
1. think
Advanced strategic thinking and analysis using openai-reasoning model.
Parameters:
text(required): The topic, question, or problem to analyzemodel(optional): AI model to use (default: openai-reasoning)seed(optional): Random seed for reproducible resultsmaxCycles(optional): Maximum thinking cycles (default: 3, max: 5)
Example:
{
"name": "think",
"arguments": {
"text": "Should a startup focus on growth or profitability first?",
"maxCycles": 3
}
}2. search
Search the web in real-time using SearchGPT model.
Parameters:
query(required): The search query to find information on the web
Example:
{
"name": "search",
"arguments": {
"query": "latest AI developments 2024"
}
}3. continue_thinking
Continue receiving the next part of a large thinking response.
Parameters: None
Example:
{
"name": "continue_thinking",
"arguments": {}
}π Installation
Clone the repository:
git clone <repository-url> cd pollinations-think-mcpInstall dependencies:
npm installStart the server:
npm start
π§ͺ Testing
Run Basic Tests
npm testTest Search Functionality
node test-search.jsManual API Testing
Test the SearchGPT endpoint directly:
# PowerShell
(Invoke-WebRequest -Uri 'https://text.pollinations.ai/your query here/?model=searchgpt' -Method Get).Contentπ API Endpoints Used
Thinking (OpenAI Reasoning)
URL:
https://text.pollinations.ai/{prompt}/?model=openai-reasoning&token=Method: GET
Purpose: Advanced reasoning and strategic analysis
Search (SearchGPT)
URL:
https://text.pollinations.ai/{prompt}/?model=searchgpt&token=Method: GET
Purpose: Real-time web search and current information retrieval
π§ Configuration
MCP Client Setup
Add to your MCP client configuration:
{
"mcpServers": {
"pollinations-think": {
"command": "node",
"args": ["/path/to/pollinations-think-mcp/index.js"]
}
}
}Environment Variables
No environment variables required - the server uses public Pollinations.ai endpoints.
π Response Handling
Large Response Management
Responses exceeding ~30KB are automatically split
Use
continue_thinkingtool to get subsequent partsContinuation data is maintained across calls
Error Handling
Comprehensive error messages for debugging
Graceful fallbacks for API failures
Detailed logging for troubleshooting
π― Use Cases
Strategic Thinking
Business strategy development
Problem-solving and decision making
Risk assessment and mitigation planning
Innovation and opportunity analysis
Web Search
Current events and news research
Market research and competitive analysis
Technical documentation lookup
Real-time data verification
π Example Outputs
Think Tool Response
# π§ Advanced Strategic Thinking Analysis
## π Analysis Overview
- Topic: Should a startup focus on growth or profitability first?
- Thinking Cycles: 3
- Analysis Depth: Advanced Multi-Layer Cognitive Processing
## π― Strategic Analysis
[Comprehensive strategic framework with executive summary,
risk mitigation, success metrics, and next steps]
## π¬ Meta-Cognitive Assessment
[Quality assessment and thinking process evaluation]Search Tool Response
# π Web Search Results: latest AI developments 2024
## Recent AI Developments:
- [Trump plans executive orders to power AI growth](https://reuters.com/...)
- [Nvidia CES 2025 keynote highlights](https://apnews.com/...)
- [OpenAI's AGI roadmap for 2025](https://time.com/...)
[Detailed search results with sources and current information]π‘οΈ Security
Uses public API endpoints (no authentication required)
No sensitive data storage
Input validation and sanitization
Safe error handling
π Version History
v2.0.0
β Added real-time web search with SearchGPT
β Enhanced thinking engine with meta-cognitive assessment
β Improved response handling for large outputs
β Comprehensive testing suite
v1.0.0
Initial release with strategic thinking capabilities
DeepSeek reasoning integration
Basic MCP server implementation
π€ Contributing
Fork the repository
Create a feature branch
Make your changes
Add tests for new functionality
Submit a pull request
π License
MIT License - see LICENSE file for details.
π Acknowledgments
Pollinations.ai for providing the AI API endpoints
Model Context Protocol for the MCP framework
DeepSeek for the reasoning model
SearchGPT for real-time web search capabilities
Made with β€οΈ for the MCP community
Available Tools
3 toolscontinue_thinkingA
Continue a previous thinking session with additional context or refinement. Requires a continuation ID from a previous think operation.
| Name | Required | Description | Default |
|---|---|---|---|
| continuation_id | Yes | The continuation ID from a previous think operation | |
| additional_input | No | Additional context or questions to incorporate (optional) |
TDQS
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. While it mentions the requirement for a continuation ID, it doesn't describe what happens during continuation (does it append to previous thinking? replace it? create a new session?), what the output looks like, whether there are rate limits, or any error conditions. For a tool with no annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise with two sentences that each earn their place. The first states the purpose, the second specifies the prerequisite. There's zero waste or redundancy, and the information is front-loaded appropriately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (continuing a thinking session), no annotations, no output schema, and 100% schema coverage, the description is adequate but has clear gaps. It explains what the tool does and the prerequisite, but doesn't describe the continuation behavior, output format, or error handling. For a tool that presumably maintains state across operations, more behavioral context would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 both parameters thoroughly. The description mentions the continuation ID requirement and that additional_input is for 'additional context or questions to incorporate,' which adds some semantic context about how the parameter is used, 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Continue a previous thinking session with additional context or refinement.' It specifies the verb ('continue') and resource ('previous thinking session'), but doesn't explicitly differentiate from the 'think' sibling tool beyond mentioning it requires a continuation ID from a previous think operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: when you have a continuation ID from a previous think operation and want to add more context or refinement. It doesn't explicitly state when NOT to use it or name alternatives, but the requirement for a previous think operation implies this is for continuing rather than starting new sessions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
searchC
Perform real-time web search using SearchGPT. Returns current information from the internet on any topic.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | The search query to find information about |
TDQS
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 'real-time' and 'current information' which hints at freshness, but doesn't disclose critical traits like rate limits, authentication needs, result format, pagination, error conditions, or whether this is a read-only operation. For a web search tool with zero annotation coverage, this leaves significant gaps in understanding how the tool behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with two concise sentences that directly state the tool's function and scope. It's front-loaded with the core purpose and avoids unnecessary details. However, the second sentence could be more tightly integrated with the first for slightly better flow.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (web search with potential for varied results) and the lack of both annotations and an output schema, the description is insufficiently complete. It doesn't explain what the return values look like (e.g., list of links, summaries), error handling, or operational constraints like rate limits. For a tool that interacts with external APIs and returns unstructured data, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the single parameter 'query' fully documented in the schema. The description adds no additional parameter semantics beyond what the schema providesβit doesn't explain query formatting, length limits, or special syntax. With high schema coverage, the baseline score of 3 is appropriate as the description doesn't compensate but doesn't need to.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 specific verbs ('perform real-time web search') and resource ('using SearchGPT'), and distinguishes it from sibling tools like 'continue_thinking' and 'think' by focusing on external information retrieval rather than internal reasoning. However, it doesn't explicitly differentiate from potential alternative search tools that might exist in other contexts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 'returns current information from the internet on any topic' which implies a broad use case, but offers no explicit when/when-not instructions, prerequisites, or comparisons to sibling tools like 'continue_thinking' and 'think' that might handle different types of queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
thinkB
Advanced strategic thinking and analysis using contradiction cycles and synthesis. Processes complex topics through multiple analytical phases to develop nuanced, well-reasoned insights.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | The topic, question, or problem to analyze strategically | |
| model | No | AI model to use (default: openai-reasoning) | openai-reasoning |
| seed | No | Random seed for reproducible results (optional) |
TDQS
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 the method ('contradiction cycles and synthesis') and outcome ('nuanced insights'), but lacks details on execution time, computational cost, rate limits, or error handling. For a tool with no annotation coverage, this leaves significant gaps in understanding its operational behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured in two sentences, front-loading the core purpose ('Advanced strategic thinking and analysis') and then elaborating on the method and outcome. There is no redundant information, and every sentence contributes to understanding the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (strategic analysis with multiple phases) and the absence of both annotations and an output schema, the description is minimally adequate. It explains what the tool does but lacks details on output format, error cases, or performance characteristics, which are important for such a sophisticated tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 (text, model, seed). The description adds no additional meaning beyond what's in the schema, such as examples of 'complex topics' or guidance on model selection. Baseline 3 is appropriate when the schema handles parameter documentation effectively.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 'strategic thinking and analysis' using specific methods ('contradiction cycles and synthesis'), which distinguishes it from generic analysis. However, it doesn't explicitly differentiate from sibling tools like 'continue_thinking' or 'search' beyond mentioning 'multiple analytical phases'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for 'complex topics' requiring 'nuanced, well-reasoned insights,' suggesting it's for deep analysis rather than simple queries. However, it provides no explicit guidance on when to use this tool versus alternatives like 'continue_thinking' or 'search,' nor does it mention any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
3 tool updates
v1.0.0- First observed
continue_thinking - First observed
search - First observed
think
TDQS
Scored across 3 tools
Each tool has a clearly distinct purpose with no overlap: 'think' performs deep analysis, 'continue_thinking' refines previous analyses, and 'search' fetches real-time web information. The descriptions clearly differentiate these as separate cognitive and information-gathering functions.
The naming is mostly consistent with verb-based patterns ('think', 'search', 'continue_thinking'), but 'continue_thinking' uses a compound verb while the others are single verbs. This minor deviation doesn't significantly hinder readability or predictability.
With only 3 tools, the set feels thin for a 'Think MCP Server' that implies comprehensive cognitive support. While the tools cover core thinking and search functions, the scope suggests potential gaps in areas like summarization, comparison, or decision support that might be expected in such a domain.
The tools provide good coverage for analytical thinking and information retrieval, but there are notable gaps for a thinking server. Missing operations include tools for summarizing analyses, comparing different thinking sessions, or exporting insights, which could limit agent workflows for complex cognitive tasks.
Maintenance
Related MCP Connectors
Real-time web search, reasoning, and research through Perplexity's API
Real-time web and scholarly search with cited answers and multi-step deep research.
AI predictions, model comparison, research briefs and web search from an autonomous AI
AI predictions, model comparison, research and web search from an autonomous AI running 24/7.
Related MCP Servers
- AlicenseBqualityDmaintenanceFacilitates two-stage reasoning processes using DeepSeek for detailed analysis and supports multiple response models such as Claude 3.5 Sonnet and OpenRouter, maintaining conversation context and enhancing AI-driven interactions.2116MIT
- AlicenseBqualityDmaintenanceProvides 10 structured reasoning strategies (Chain of Thought, ReAct, Tree of Thoughts, etc.) for complex problem-solving with session persistence, branching, and tool integration capabilities.3728MIT
- AlicenseAqualityDmaintenanceProvides advanced AI reasoning capabilities through step-by-step thinking framework, enabling complex problem-solving with dynamic thought revision, multi-path reasoning, and adaptive planning for sophisticated analysis tasks.1MIT
- AlicenseAqualityNot gradedmaintenanceEnables web searching via SearXNG, page content extraction with Crawl4AI, and image analysis using vision language models. It provides AI agents with tools for information synthesis and web-based data retrieval through OpenAI-compatible LLM endpoints.3-