A multi-purpose AI-powered server enabling browser automation, audio transcription, and LLM chat as MCP tools for any agent.
Browser Automation (dat_browse): Run natural language browser tasks on a real browser. Supports sync (waits up to 10 min) or async modes, with options for screenshots, geo-routing, session grouping, timeouts, and multi-node fanout.
Browse Task Status (dat_browse_status): Poll the status of an async browser task (queued/assigned/running/completed/failed) and retrieve results when ready.
Screenshot Download (dat_browse_screenshot): Download screenshots captured during a browsing task as base64 image data.
Audio Transcription (dat_transcribe): Transcribe audio to text using Whisper, accepting audio via URL or base64-encoded data, with sync and async modes.
Transcription Status (dat_transcribe_status): Poll the status of an async transcription task.
OpenAI-Compatible Chat (dat_completions): Chat with LLMs supporting streaming, function/tool calling, and built-in dat.ai tools (network, filesystem, webview).
Ollama-Compatible Chat (dat_chat): Chat with LLMs via an Ollama-compatible interface with NDJSON streaming, system prompts, custom options (temperature, top_p, etc.), and built-in dat.ai tools (network, filesystem, webview).
Allows interaction with Ollama-compatible chat completions API, supporting NDJSON streaming, system prompts, and built-in dat.ai tools (net, fs, webview).
Allows interaction with OpenAI-compatible chat completions API, supporting streaming, function calling, and built-in dat.ai tools (net, fs, webview).
Click on "Install 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., "@dat-ai-mcp open example.com and summarize the main points"
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.
Browser automation, transcription, and LLM chat as MCP tools for any agent.
Tool | Endpoint | Description |
|
| Natural language browser automation. Sync (waits up to 10 min) or async (returns task_id immediately). Optional screenshots |
|
| Poll an async browsing task. Returns status + result if ready |
|
| Download a screenshot as base64 image data |
|
| Whisper speech-to-text. Accepts audio URL or base64. Sync or async |
|
| Poll an async transcription task |
|
| OpenAI-compatible chat completions. Streaming, function calling, built-in dat.ai tools (net/fs/webview) |
|
| Ollama-compatible chat. NDJSON streaming, system prompts, built-in tools |
Related MCP server: openclaw-tools-mcp
Sign up at dat.ai and get your API key from the dashboard. See the official API docs for reference.
hermes plugins install willtholke/dat.ai-mcp --enableRestart Hermes after installing. Set your API key in ~/.hermes/.env:
DAT_AI_API_KEY=your-api-key-hereThe plugin registers all 7 tools as native Hermes tools. No MCP config needed.
Install the package:
pip install dat-ai-mcpOr use directly with uvx (no install needed):
uvx dat-ai-mcpSet the DAT_AI_API_KEY environment variable and add the server to your MCP client config
Add to claude_desktop_config.json:
{
"mcpServers": {
"dat-ai": {
"command": "uvx",
"args": ["dat-ai-mcp"],
"env": {
"DAT_AI_API_KEY": "your-api-key-here"
}
}
}
}Same pattern: command uvx, args ["dat-ai-mcp"], env DAT_AI_API_KEY
DAT_AI_API_KEY=your-api-key-heredat_browse({
task: "Open https://example.com and summarize the page",
screenshots_mode: "final_only"
})dat_transcribe({
audio_url: "https://example.com/audio.mp3"
})dat_completions({
model: "qwen3:1.7b",
messages: [{ role: "user", content: "Open https://example.com and summarize the page" }],
datai_tools: { net: true, webview: true }
})If the dat.ai tools don't show up after installing the plugin:
Don't also add an MCP server entry. The Hermes plugin registers all 7 tools as native Hermes tools. Adding a dat-ai entry to mcp_servers in config.yaml creates a redundant subprocess that can conflict with the native plugin. The plugin is the correct path — no MCP config needed.
Verify the plugin is enabled:
hermes plugins listdat-ai should show as enabled.
Verify the toolset is enabled for your platform:
hermes tools listdat-ai should appear under "Plugin toolsets" as enabled. If not, run hermes tools and enable it.
Restart Hermes after config changes. Plugin tool definitions are cached per-session.
git clone https://github.com/willtholke/dat.ai-mcp.git
cd dat.ai-mcp
python -m venv .venv
source .venv/bin/activate
pip install -e .Special thanks to dat.ai co-founder & COO Eugenia Dushina for setting me up with the platform
Run a browser automation task on dat.ai. Give a natural language instruction and dat.ai will drive a real browser to complete it. Returns the result and any screenshot URLs. Uses sync mode by default (waits for completion, up to 10 min). Set async=true to get a task_id immediately and poll with dat_browse_status.
| Name | Required | Description | Default |
|---|---|---|---|
| task | Yes | The instruction to execute in the browser, e.g. 'Open https://example.com and summarize the page' | |
| async | No | If true, return a task_id immediately instead of waiting. Poll with dat_browse_status. Default: false | |
| fanout | No | Number of nodes to race the task on (1-10, default 1). Optional. | |
| timeout | No | Task timeout in milliseconds (max 10800000 = 3 hours). Optional. | |
| full_page | No | Used by final_only mode. Capture full scrollable page. Default: true. | |
| country_iso | No | Route to browsing nodes in this country (ISO code, e.g. 'US', 'DE'). Optional. | |
| session_key | No | Group browsing tasks into a shared session. Optional. | |
| screenshots_mode | No | Screenshot capture mode. final_only: one screenshot after completion. every_step: screenshot each step. on_navigation: screenshot on URL change. Default: none (no screenshots). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses sync/async behavior, default mode, return format (result and screenshot URLs), and mentions optional parameters that affect behavior (fanout, country routing, session grouping, screenshot modes). It does not mention destructive potential or authentication needs, but the nature of the tool implies read/write possibilities in browsing. The description adds value beyond the schema by explaining the default wait time and polling pattern.
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 three sentences, each serving a distinct purpose: stating the action, describing output, and explaining modes. It is front-loaded with the core functionality and highly efficient with zero wasted words.
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?
While the description covers the main task and sync/async modes, it lacks details on error handling, return value structure (since no output schema is provided), rate limits, and authentication. For a tool with 8 parameters and no output schema, the description should provide more context on expected results and edge cases to fully inform an AI agent.
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 baseline is 3. The description only briefly mentions async mode and timeouts (up to 10 min in sync), adding marginal semantic value beyond parameter descriptions. It does not elaborate on other parameters like fanout, country_iso, or screenshots_mode in the prose itself.
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?
Description clearly states the tool runs browser automation tasks from natural language instructions on dat.ai, and specifies that it returns results and screenshot URLs. It distinguishes sync and async modes but doesn't explicitly differentiate from sibling tools, though the role is evident.
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 guidance on when to use sync vs async mode, including details that sync waits up to 10 minutes and async returns an ID immediately for polling with dat_browse_status. However, it does not discuss when to choose this tool over siblings like dat_browse_screenshot, though the sibling relationship suggests they are complementary rather than alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Download a screenshot from a completed dat.ai browsing task. Returns the image as base64 data.
| Name | Required | Description | Default |
|---|---|---|---|
| task_id | Yes | The browsing task ID. | |
| filename | Yes | The screenshot filename, e.g. 'screenshot-01.png'. Get filenames from the browsing result. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provide safety or behavioral cues. Description mentions 'completed' prerequisite but does not disclose potential errors, size limits, or whether multiple calls are safe. Basic behavioral info is present but incomplete.
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?
Single sentence is concise and front-loaded with main action. No wasted words, though could be slightly more structured (e.g., separate output format).
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?
For a simple download tool with no output schema, description covers core function and params but misses details like base64 encoding format, error handling, or any prerequisites beyond task completion.
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 coverage is 100% with both parameters described. Description adds minimal value beyond schema, only hinting to get filenames from browsing result. Baseline score appropriate.
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?
Description clearly states action (download), resource (screenshot from browsing task), and output format (base64). Distinguishes from sibling tools like dat_browse (starts task) and dat_browse_status (checks status).
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?
Description implies use after task completion but lacks explicit guidance on when to use vs alternatives, such as referencing dat_browse_status to check completion first.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check the status of an async dat.ai browsing task. Returns status (queued/assigned/running/completed/failed) and result if ready.
| Name | Required | Description | Default |
|---|---|---|---|
| task_id | Yes | The task_id returned from dat_browse with async=true. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description covers return values and statuses but omits idempotency, rate limits, or whether results are consumed. For a simple status checker, this is acceptable but not comprehensive.
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?
Two concise sentences, no fluff. Front-loaded with verb and resource, then details. Every sentence adds value.
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?
For a single-parameter, no-output-schema tool, the description covers purpose, usage context, and return types. Minor gaps like polling behavior or error handling exist but are not critical given tool simplicity.
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?
With 100% schema description coverage, the description reinforces the schema but adds little new semantic meaning. It echoes the schema's mention of async=true context, but does not elaborate on format or constraints.
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 checks status of an async browsing task and lists possible statuses, distinguishing it from sibling tools like dat_browse (initiates) and dat_transcribe_status (for transcription).
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 notes the task_id comes from dat_browse with async=true, providing a usage hint. However, it does not explicitly state when not to use or compare to other status tools like dat_transcribe_status.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ollama-compatible chat endpoint via dat.ai. Supports NDJSON streaming and non-streaming. Can enable built-in tools (net, fs, webview). Note: tools cannot be used with streaming.
| Name | Required | Description | Default |
|---|---|---|---|
| model | Yes | Model name, e.g. 'qwen3:1.7b' | |
| stream | No | Enable NDJSON streaming. Default: false. | |
| system | No | System prompt. Optional. | |
| options | No | Ollama options (temperature, top_p, top_k, num_predict, num_ctx, stop, seed). Optional. | |
| messages | Yes | Chat messages array. | |
| datai_tools | No | dat.ai built-in tools. Cannot be used with stream=true. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes key behaviors (NDJSON streaming, built-in tools, tool-streaming incompatibility) but with no annotations, misses return format and error details.
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?
Three concise, front-loaded sentences, each adding essential detail with no redundancy.
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?
Adequate for a chat tool but lacks output schema description and doesn't cover error cases like enabling tools with streaming, leaving some gaps for agent understanding.
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 covers all parameters with 100% description coverage; description adds value for streaming/tools interplay but doesn't enrich individual parameter meanings beyond schema.
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 identifies the tool as an Ollama-compatible chat endpoint via dat.ai, distinguishes it from sibling browsing/transcription tools by its chat function.
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?
Provides clear usage context: streaming vs non-streaming, and the constraint that tools cannot be used with streaming. However, lacks explicit differentiation from sibling dat_completions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
OpenAI-compatible chat completions via dat.ai. Supports streaming and non-streaming. Can enable built-in tools (net, fs, webview) via the datai.tools parameter. Note: tools cannot be used with streaming.
| Name | Required | Description | Default |
|---|---|---|---|
| seed | No | Random seed. Optional. | |
| stop | No | Stop sequence(s). Optional. | |
| model | Yes | Model name, e.g. 'qwen3:1.7b' | |
| tools | No | OpenAI function-calling tools. Optional. | |
| top_p | No | Nucleus sampling parameter. Optional. | |
| stream | No | Enable streaming. Default: false. | |
| messages | Yes | Chat messages array. | |
| max_tokens | No | Maximum tokens to generate. Optional. | |
| datai_tools | No | dat.ai built-in tools. Cannot be used with stream=true. | |
| temperature | No | Sampling temperature. Optional. | |
| tool_choice | No | Tool choice strategy. Optional. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must disclose behavior. It covers streaming and tool restrictions, but does not mention other aspects like auth needs or response format.
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?
Three concise sentences with no redundancy. The first sentence immediately conveys the tool's purpose.
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?
Covers key constraints (streaming, tools) but lacks explanation of return values, e.g., streaming response format. Still adequate given tool complexity.
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 coverage is 100%, so baseline 3. The description explains that datai_tools cannot be used with streaming, adding value beyond 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 it provides OpenAI-compatible chat completions via dat.ai, distinguishing it from sibling tools like dat_browse and dat_transcribe which serve different purposes.
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?
It mentions support for streaming/non-streaming and a constraint on using built-in tools with streaming, but does not explicitly guide when to prefer this tool over alternatives like dat_chat.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Transcribe audio to text using dat.ai's Whisper API. Provide audio as a URL (the server will fetch it) or as base64-encoded data. Returns transcribed text. Uses sync mode (waits for completion, up to 10 min).
| Name | Required | Description | Default |
|---|---|---|---|
| async | No | If true, return a task_id immediately. Poll with dat_transcribe_status. Default: false. | |
| audio_url | No | URL of the audio file to transcribe. The server will download and transcribe it. | |
| audio_base64 | No | Base64-encoded audio data. Will be sent as raw bytes. | |
| content_type | No | Content-Type of the audio when using audio_base64, e.g. 'audio/wav', 'audio/mpeg', 'audio/mp4'. Default: 'audio/wav'. | audio/wav |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool uses sync mode and waits up to 10 minutes, which is important behavioral info. However, it lacks details on rate limits, authentication requirements, error handling, or what happens on timeout, leaving gaps 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (three sentences) and front-loaded with the core purpose. Each sentence adds essential information without unnecessary elaboration, making it easy for an AI agent to quickly grasp the tool's functionality.
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 has 4 parameters, no output schema, and no annotations, the description covers the key aspects: input methods, sync/async behavior, and timeout. It does not detail the output format beyond 'transcribed text' or error behavior, but for a straightforward transcribe tool, this is largely sufficient.
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 coverage is 100%, so baseline is 3. The description adds value by explaining that audio_url is fetched by the server and audio_base64 is sent as raw bytes, and that async defaults to false. However, it does not provide format or validation details beyond what the schema already describes, so no extra semantic enrichment.
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: transcribe audio to text using dat.ai's Whisper API. It specifies the two methods of providing audio (URL or base64-encoded data) and distinguishes itself from siblings like dat_transcribe_status for polling, making its role unambiguous.
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 on when to use sync mode (default) vs async mode (by setting async=true and polling with dat_transcribe_status). It also explains the two ways to provide audio input. However, it does not explicitly state when not to use the tool or mention alternatives beyond the sync/async choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check the status of an async dat.ai transcription task.
| Name | Required | Description | Default |
|---|---|---|---|
| task_id | Yes | The task_id returned from dat_transcribe with async=true. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states the purpose, omitting details like whether the tool is read-only, what the response format is, or any polling 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 a single sentence, fully front-loaded, with no unnecessary words. It efficiently conveys the essential purpose.
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?
For a simple status-check tool with one parameter and no output schema, the description is adequate but minimal. It does not explain what the response contains (e.g., possible statuses), leaving some uncertainty about the tool's output.
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 already documents the single parameter 'task_id' with a clear description. The tool description adds no further meaning beyond what the schema provides, warranting the baseline score.
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 verb ('check') and resource ('status of an async dat.ai transcription task'), distinguishing it from sibling tools like 'dat_transcribe' (which initiates tasks) and other browsing/completion tools.
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 context by mentioning 'async dat.ai transcription task,' indicating it should be used after 'dat_transcribe' with async=true. However, it lacks explicit when-not-to-use guidance or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0dat_browsedat_browse_screenshotdat_browse_statusdat_chatdat_completionsdat_transcribedat_transcribe_statusMost tools have distinct purposes, but dat_chat and dat_completions are very similar (both chat endpoints with same features), which could cause misselection. The descriptions help differentiate, but overlap exists.
All tools share the 'dat_' prefix and follow a verb or verb_noun pattern. Async status tools use 'status' suffix. The naming is consistent and predictable.
7 tools is well-scoped for an AI service covering browsing, chat, and transcription. Each tool serves a clear purpose without redundancy.
The tool set covers all core features: browsing (sync/async, status, screenshot), chat (two API styles), and transcription (sync/async, status). No obvious gaps for the stated domain.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
OCR, transcription, file extraction, and image generation for AI agents via MCP.
Your org's AI agents, tasks, runs, search, and brain files as MCP tools and resources.
Scrape, crawl and search the web for AI agents via MCP.
Hosted MCP runtime where the agent is the operator: sign up by tool call, publish your own tools.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/willtholke/dat.ai-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
