Which integrations are available for this server?

Provides tools for web search, web fetch, chat completion, and search-and-chat using Ollama's models and hosted API, with support for local Ollama instances.

How do I use Ollama MCP Server?

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., "@Ollama MCP Server search latest Python async patterns" 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.

Ollama MCP Server

by timscodebase

Overview Schema Related Servers Score Discussions

Python

Hybrid

Ollama MCP Server with Qwen3-Coder

A Model Context Protocol (MCP) server that provides web search, web fetch, and chat completion capabilities using Ollama's Qwen3-coder models. Designed to work seamlessly with Cursor IDE and other MCP-compatible clients.

Features

Smart Model Selection: Automatically uses qwen3-coder:480b-cloud when API key is available, falls back to local models
Web Search: Powered by Ollama's hosted search API
Web Fetch: Retrieve and parse content from specific URLs
Chat Completion: High-quality code-focused conversations with Qwen3-coder
Search & Chat: Combined tool that searches the web and generates responses based on results
Automatic Fallback: Falls back to local models (qwen3:4b, qwen3:7b, etc.) when cloud is unavailable

Related MCP server: WebQuest MCP

Installation

Clone or download this repository
Install dependencies using uv (recommended) or pip:

# Using uv (recommended)
uv sync

# Or using pip
pip install -e .

Configuration

Environment Variables

OLLAMA_API_KEY (optional): Required for cloud models and web search/fetch functionality
OLLAMA_HOST (optional): Ollama server URL (default: http://localhost:11434)

For Cursor IDE

Open Cursor IDE settings
Go to "Extensions" → "MCP" → "Manage MCP Servers"
Add the configuration from cursor-mcp-config.json:

{
  "mcpServers": {
    "ollama-qwen-mcp": {
      "type": "stdio", 
      "command": "uv",
      "args": ["run", "python", "-m", "ollamamcp.server"],
      "env": {
        "OLLAMA_API_KEY": "your_api_key_here_or_remove_for_local_only",
        "OLLAMA_HOST": "http://localhost:11434"
      }
    }
  }
}

For Other MCP Clients

The server can be run directly:

# With API key for cloud features
OLLAMA_API_KEY=your_key uv run python -m ollamamcp.server

# Local only (no web search/fetch)
uv run python -m ollamamcp.server

Available Tools

1. `web_search`

Perform web searches using Ollama's hosted API.

Parameters:

query (str): Search query
max_results (int): Maximum results (default: 3, max: 20)

Requires: OLLAMA_API_KEY

2. `web_fetch`

Fetch content from a specific URL.

Parameters:

url (str): Absolute URL to fetch

Requires: OLLAMA_API_KEY

3. `chat_completion`

Generate responses using Qwen3-coder models.

Parameters:

messages (list): Conversation messages
model (str, optional): Override model selection
temperature (float): Sampling temperature (default: 0.7)
max_tokens (int, optional): Maximum tokens to generate

4. `search_and_chat`

Combined web search and chat completion.

Parameters:

query (str): Search query and question
search_results (int): Number of results (default: 3)
model (str, optional): Override model selection
temperature (float): Sampling temperature (default: 0.7)

Requires: OLLAMA_API_KEY

5. `get_available_models`

Get information about available models and configuration.

Returns: Current model, availability status, and model lists.

Model Fallback Strategy

Cloud First: qwen3-coder:480b-cloud (if API key available)
Local Fallbacks (in order):
- qwen3:4b
- qwen3:7b
- qwen3:14b
- qwen2.5-coder:7b
- qwen2.5-coder:3b
- qwen2.5-coder:1.5b

The server automatically pulls local models if they're not available but Ollama is running.

Usage Examples

In Cursor IDE

Once configured, you can use natural language to:

"Search for the latest Python async/await best practices"
"Fetch the documentation from https://docs.python.org/3/library/asyncio.html"
"What are the new features in the latest Django release?"

Direct API Usage

import json
import subprocess

# Example: Web search and chat
result = subprocess.run([
    "uv", "run", "python", "-m", "ollamamcp.server"
], input=json.dumps({
    "jsonrpc": "2.0",
    "id": 1,
    "method": "tools/call",
    "params": {
        "name": "search_and_chat",
        "arguments": {
            "query": "latest Python asyncio patterns",
            "search_results": 5
        }
    }
}), text=True, capture_output=True)

print(result.stdout)

Requirements

Python 3.12+
Ollama (for local models)
Internet connection (for cloud models and web search)

Troubleshooting

No Models Available

Ensure Ollama is running: ollama serve
Pull a local model: ollama pull qwen3:4b

Web Search/Fetch Not Working

Verify OLLAMA_API_KEY is set and valid
Check internet connection

Cloud Model Not Available

Verify API key has access to cloud models
Server will automatically fall back to local models

License

This project follows the same license as the Ollama Python library.

Available Tools

5 tools

chat_completionB

    Generate a chat completion using Qwen3-coder (cloud preferred, local fallback).

    Args:
        messages: List of message objects with 'role' and 'content' keys.
        model: Optional model override (default: auto-selected best available).
        temperature: Sampling temperature (0.0 to 2.0, default: 0.7).
        max_tokens: Maximum tokens to generate.
        **kwargs: Additional parameters for the chat API.

    Returns:
        JSON-serializable dict with the model response.

ParametersJSON Schema

Name	Required	Description	Default
`model`	No
`kwargs`	Yes
`messages`	Yes
`max_tokens`	No
`temperature`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.3/5.0

Behavior3/5

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

No annotations are provided, so the description carries the full disclosure burden. It adds useful behavioral context: cloud-prefered with local fallback and auto-selected model unless overridden. However, it does not disclose error behavior, side effects, auth requirements, or what happens when the fallback is triggered, leaving notable gaps.

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 a well-structured docstring with a one-line summary, then concise Args and Returns entries. There is little filler and each line contributes information. A minor redundancy is the Returns section, which may duplicate what the output schema already provides.

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?

For a chat completion tool with five params and no annotations, the description covers the core call and most parameters. However, it leaves the required kwargs format unexplained, does not specify when to use this tool instead of search_and_chat, and omits fallback/error behavior. These gaps make it adequate but not fully 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?

Schema description coverage is 0%, so the Args block meaningfully compensates. It explains message format (role/content), model override behavior, temperature range and default, and max_tokens purpose. The required kwargs parameter is only described as 'Additional parameters for the chat API' without explaining its string encoding, so the compensation is not complete.

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 opens with 'Generate a chat completion using Qwen3-coder', naming a specific verb and resource. It clearly identifies the model and the cloud/local fallback behavior. However, it does not distinguish itself from the sibling tool search_and_chat, so it stops short of full differentiation.

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 when-to-use guidance and does not mention any alternative tools. Given the sibling search_and_chat, an agent could easily be uncertain which completion tool to select, and the description does not resolve that ambiguity. Usage is only implied by the tool name and the verb 'generate'.

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

get_available_modelsA

    Get information about available models and current configuration.

    Returns:
        JSON-serializable dict with model availability information.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

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 carries the burden of behavioral disclosure. It does say the tool returns a 'JSON-serializable dict' and describes the operation as 'Get information', implying a read-only call, but it does not explicitly address side effects, permissions, caching, or failure behavior.

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 short sentences with no filler, and the core purpose is front-loaded. The return type note is separated clearly and earns its place without unnecessary elaboration.

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 zero-parameter, read-oriented metadata tool with an output schema present, the description is mostly complete. It names the resource and return shape; the only minor gap is the absence of any guidance about when this tool should be chosen over sibling tools, but that does not seriously impede correct invocation.

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 the input schema confirms an empty properties object, so there are no parameter semantics to explain. The baseline of 4 applies because no parameter documentation is 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 names a specific verb ('Get') and resource ('available models and current configuration'), so an agent can immediately tell what the tool does. It also distinguishes itself from the sibling tools (web_search, web_fetch, chat_completion, search_and_chat), which are clearly about web access or generation rather than model metadata.

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?

No explicit when-to-use or when-not-to-use guidance is provided, and no alternatives are mentioned. However, the resource named in the description and the zero-parameter signature imply this is the tool to call when an agent needs model availability or configuration information.

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

search_and_chatA

    Perform web search and then generate a response based on the search results.
    
    This is a convenience tool that combines web_search and chat_completion.
    Requires OLLAMA_API_KEY environment variable to be set for web search.

    Args:
        query: The search query and question to answer.
        search_results: Number of search results to include (default: 3).
        model: Optional model override.
        temperature: Sampling temperature for chat completion.

    Returns:
        JSON-serializable dict with search results and AI response.

ParametersJSON Schema

Name	Required	Description	Default
`model`	No
`query`	Yes
`temperature`	No
`search_results`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4/5.0

Behavior3/5

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

There are no annotations, so the description carries the full burden. It discloses the OLLAMA_API_KEY requirement, the combined search-and-chat behavior, and the return shape. However, it does not mention external service effects, failure modes, latency, or behavior when the API key is missing or invalid.

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 well structured and front-loaded with the core purpose. The Args and Returns sections are slightly redundant with the provided schema but still concise and useful.

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 complexity, the description covers purpose, parameters, environment requirements, and return format. Yet it lacks guidance on when to choose this combined tool versus calling web_search or chat_completion separately, and it does not address error handling or operational caveats.

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 description coverage is 0%, so the description must explain the parameters, and it does so adequately: query, search_results count, optional model override, and temperature. It adds meaningful context beyond the raw schema, though it lacks deeper details like temperature ranges or search_results limits.

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 performs a web search and then generates a response, explicitly naming it as a convenience tool that combines web_search and chat_completion. This makes its function and differentiation from siblings immediately understandable.

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?

It clearly implies use when both web search and chat generation are needed, and it names the combined components. However, it does not explicitly state when to prefer the separate tools instead, such as when only search or only chat completion is needed.

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

web_fetchA

    Fetch the content of a web page for the provided URL.
    
    Requires OLLAMA_API_KEY environment variable to be set.

    Args:
        url: The absolute URL to fetch.

    Returns:
        JSON-serializable dict with page title, content, and links.

ParametersJSON Schema

Name	Required	Description	Default
`url`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.4/5.0

Behavior4/5

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

No annotations are provided, so the description carries the behavioral disclosure burden. It reveals an important environmental prerequisite (OLLAMA_API_KEY) and describes the return shape as a JSON-serializable dict with title, content, and links, which adds real context beyond the schema.

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 compact and organized with clear Args and Returns sections. Every sentence contributes necessary information, though the docstring-style formatting is slightly more verbose than a single crisp sentence.

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 tool with an output schema, the description provides the essential prerequisite, the URL requirement, and a summary of the return value. It does not discuss error behavior or when to prefer sibling tools, but the core details needed to invoke it correctly are present.

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?

Although the schema itself provides no description for url, the tool description explicitly explains that url is 'the absolute URL to fetch.' This adds meaningful format guidance beyond the bare string type and fully covers the only parameter.

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 a specific action and object: 'Fetch the content of a web page for the provided URL.' This distinguishes it from siblings like web_search, which finds pages rather than retrieving a specified page's content.

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 use: it fetches a provided URL and requires the OLLAMA_API_KEY environment variable. It does not explicitly contrast with alternatives like web_search, but the purpose and prerequisite are sufficiently clear.

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

web_searchA

    Perform a web search using Ollama's hosted search API.
    
    Requires OLLAMA_API_KEY environment variable to be set.

    Args:
        query: The search query to run.
        max_results: Maximum results to return (default: 3, max: 20).

    Returns:
        JSON-serializable dict with search results including titles, URLs, and content snippets.

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes
`max_results`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.1/5.0

Behavior4/5

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

With no annotations provided, the description carries the behavioral disclosure burden. It discloses the required environment variable and the JSON-serializable result shape containing titles, URLs, and snippets. It does not mention failure modes, rate limits, or latency, but for a search tool the disclosed behavior is solid.

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 compact and front-loaded: the action is stated immediately, followed by the prerequisite, parameters, and return format. Every sentence earns its place, with no filler or redundant marketing language.

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 two-parameter tool with an output schema, the description covers the prerequisite, parameter constraints, and return format, which is largely complete. It stops short of a 5 because it does not address when to prefer web_fetch, chat_completion, or search_and_chat, or what happens when the API key is invalid.

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?

Schema description coverage is 0%, and the description fully compensates by explaining both parameters: query is the search query, and max_results is the maximum result count with default 3 and max 20. It even adds the max:20 constraint that the schema does not express.

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 action ('Perform a web search') and the resource ('Ollama's hosted search API'), making the tool's purpose specific and understandable. However, it does not explicitly contrast itself with sibling tools like search_and_chat or web_fetch, so it misses the top score for sibling 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 whenever a web search is requested and states the OLLAMA_API_KEY prerequisite. However, it gives no explicit when-to-use vs. when-not-to-use guidance and does not mention alternatives such as search_and_chat for combined search-and-answer scenarios.

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. Dates show when Glama detected each change.

5 tool updatesv0.1.0Aug 30, 2026
- First observedchat_completion
- First observedget_available_models
- First observedsearch_and_chat
- First observedweb_fetch
- First observedweb_search

Install Server

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

TDQS

A3.8/5.0

Disambiguation4/5

Most tools have clear boundaries: web_search finds pages, web_fetch retrieves a specific URL, chat_completion generates responses, and search_and_chat explicitly combines search and chat. The main ambiguity is between chat_completion and search_and_chat, but their descriptions make the distinction clear.

Naming Consistency3/5

Naming is readable and consistent in style (snake_case), but lacks a unifed verb_noun pattern: web_search/web_fetch share a prefixed verb, get_available_models uses get_, chat_completion is a bare noun phrase, and search_and_chat is a compound verb. This is mixed but not chaotic.

Tool Count5/5

Five tools is a well-scoped size for a search-and-chat helper. Each tool has a discernible purpose and none feels redundant.

Completeness4/5

The core workflows—web search, page fetching, listing models, plain chat, and search-grounded chat—are all covered. Missing Ollama-specific operations like embedding generation or model management, but those feel like minor gaps given the server's apparent focus.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

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.

Related MCP Connectors

hithereiamaliff-mcp-nextcloudOAuth
ai.smithery
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Cloud Storage File Systems Workplace & Productivity
237
mcp A
ai.llmse
Public MCP server for the LLM Search Engine
Search RAG Systems Developer Tools
102
Keenable Web Search A
ai.keenable.api
Docs: https://docs.keenable.ai/mcp-server Keenable is a free, remote MCP server that gives agents access to the web index. Search the web with ranked results and date/site filters, then fetch any indexed page as clean markdown. Works out of the box with no account or API key.
Research & Data Search Web Scraping
23
Mercado PagoOAuth
com.mercadopago.mcp
The Mercado Pago MCP Server implements the Model Context Protocol to provide AI agents and LLMs with access to Mercado Pago's APIs and tools within compatible development environments. It acts as an intermediary that translates Mercado Pago resources into executable functions (tools) that AI applications can invoke to perform actions and automate flows. The server simplifies integration, enables using documentation to implement or improve code, and optimizes operations through natural language interactions without manual implementations.
Finance E-commerce & Retail App Automation
2

Related MCP Servers

OneSearch MCP Server
Browser Automation Web Scraping Search
yokingma
A
license
A
quality
A
maintenance
A Model Context Protocol server that enables web search, scraping, crawling, and content extraction through multiple engines including SearXNG, Firecrawl, and Tavily.
Updated a month ago (2026-07-31 01:37 UTC)
4
190
139
MIT
WebQuest MCP
Browser Automation Web Scraping
mustafametesengul
A
license
Not graded
quality
C
maintenance
A Model Context Protocol server that exposes powerful web search and scraping tools to AI agents and MCP-compatible clients.
Updated 7 months ago (2026-02-12 20:56 UTC)
Apache 2.0
myscrape
Browser Automation Web Scraping Search
Bonifatius94
A
license
Not graded
quality
A
maintenance
A self-contained web-research MCP server that lets local LLM agents search, fetch, and synthesize web content using tools like web_search, web_fetch, and web_research.
Updated 11 days ago (2026-08-26 18:34 UTC)
1
MIT
Qwen3 MCP Server
AI & Machine Learning Developer Tools
WOODSEE-DIGI
A
license
Not graded
quality
C
maintenance
Multi-model MCP server enabling code generation, visual analysis, and complex reasoning via Qwen3 models.
Updated 2 months ago (2026-07-04 05:59 UTC)
MIT

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/timscodebase/ollamaMCP'

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

Ollama MCP Server with Qwen3-Coder

Features

Installation

Configuration

Environment Variables

For Cursor IDE

For Other MCP Clients

Available Tools

1. web_search

2. web_fetch

3. chat_completion

4. search_and_chat

5. get_available_models

Model Fallback Strategy

Usage Examples

In Cursor IDE

Direct API Usage

Requirements

Troubleshooting

No Models Available

Web Search/Fetch Not Working

Cloud Model Not Available

License

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

1. `web_search`

2. `web_fetch`

3. `chat_completion`

4. `search_and_chat`

5. `get_available_models`