Provides access to community-curated resources about OpenAI Dots, enabling users to list and search Dots-related resources by section and keyword. Dots-native tools are planned once a public OpenAI Dots API is available.
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., "@dots-mcp search Dots resources for news about proactive agents"
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.
An MCP server for OpenAI Dots — the always-on, proactive agents announced at DevDay 2026.
Unofficial. Not affiliated with or endorsed by OpenAI.
OpenAI has not published a public Dots API yet. Until it does, dots-mcp gives any MCP client (Claude, Cursor, ChatGPT, etc.) live, searchable access to the community-curated awesome-dots list. Dots-native tools will be added here as soon as an API is available.
Related MCP server: Docs Vector MCP
Tool | Description |
| List resources, optionally filtered by section ( |
| Keyword search across names, descriptions and sections. |
The list is fetched from GitHub and cached for 10 minutes. Override the source with DOTS_LIST_URL.
git clone https://github.com/mergisi/dots-mcp.git
cd dots-mcp
npm install && npm run buildclaude mcp add dots -- node /absolute/path/to/dots-mcp/dist/index.js{
"mcpServers": {
"dots": {
"command": "node",
"args": ["/absolute/path/to/dots-mcp/dist/index.js"]
}
}
}Search the awesome-dots resource list
Dots-native tools (send a task, check status, list Dots) once OpenAI ships a public API
npm package (npx dots-mcp)
Issues and PRs welcome. To add a resource to the list, open a PR on awesome-dots.
MIT
List resources about OpenAI Dots from the awesome-dots list, optionally filtered by section (e.g. Official, News & Coverage, Tools & Integrations).
| Name | Required | Description | Default |
|---|---|---|---|
| section | No | Section name to filter by (case-insensitive substring) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden; it discloses the data source (awesome-dots list) and that filtering is optional, which is useful. However, it says nothing about ordering, result volume, or whether unfiltered listing returns everything, which matters for a list tool with no output schema.
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?
One sentence, front-loaded with the verb and resource, with the optional modifier trailing. Nothing is wasted.
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 one-parameter read-only list tool with no output schema needed, the description covers the source, scope, and filter adequately. The remaining gap is routing relative to its sibling search tool, which is not addressed.
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% and the single parameter is documented there, so the baseline is met. The description goes further by supplying concrete section-name examples (Official, News & Coverage, Tools & Integrations) that the schema does not, helping the agent choose a real filter value.
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?
States a specific verb ('List') and a well-scoped resource ('resources about OpenAI Dots from the awesome-dots list'), and clarifies the optional section filter. It does not, however, distinguish itself from the sibling search_dots_resources, so an agent must guess how 'list' differs from 'search'.
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 hints at a browse-style call with an optional filter, but never states when to use this versus search_dots_resources. There is no exclusion or alternative guidance despite an obvious overlapping sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the awesome-dots list for OpenAI Dots guides, news, tools and use cases by keyword.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Keyword(s) to search in names, descriptions and sections |
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 implies a read-only keyword search but says nothing about result format, ranking, pagination, or scope limits, leaving the agent to assume 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?
A single, front-loaded sentence that states the verb, target corpus, content types, and search mode with no filler. Every phrase contributes to identifying the tool.
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 one-parameter search tool with no output schema and no annotations, the description covers the essential purpose but omits sibling differentiation and any behavioral details such as result ordering. Adequate but with clear gaps.
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 the single 'query' parameter is already well documented in the schema. The description adds only that matching is 'by keyword,' which does not meaningfully extend the schema's explanation, so the baseline of 3 for high coverage applies.
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 states a specific verb ('Search') and resource ('the awesome-dots list for OpenAI Dots guides, news, tools and use cases'), making the tool easy to identify. It does not, however, explicitly contrast itself with the sibling list_dots_resources, leaving sibling differentiation to inference.
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 phrase 'by keyword' hints at when the tool is appropriate, but there is no explicit guidance on when to use it versus list_dots_resources, nor any exclusions or prerequisites. The agent must infer the search-vs-list distinction on its own.
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.
v0.1.0list_dots_resourcessearch_dots_resourcesScored across 2 tools
list_dots_resources and search_dots_resources both retrieve from the same dataset, but the list vs. keyword-search split is a clear, conventional distinction. An agent can easily choose the right tool based on whether it wants to enumerate/filter by section or query by keyword.
Both names use consistent snake_case with a verb_noun pattern (list_dots_resources, search_dots_resources) and share the same noun phrase. There is no deviation or mixed convention.
Two tools is on the thin side for a resource-access server; while both are warranted, the surface feels minimal. A third tool (e.g., get resource details) could round it out, but the current count is not unreasonable for a narrow, read-only list.
The domain is a curated resource list about OpenAI Dots; listing (with optional section filter) and keyword search cover the primary retrieval needs. However, there is no explicit operation to fetch a single resource by ID or to list available sections, leaving minor gaps an agent may need to work around.
Search and fetch AI agent skills, rules files and MCP servers indexed from GitHub.
Read-only search and Markdown access to liz's public docs, prompts, resources, and an MCP App.
Search a public index of agents, MCP servers and skills found on the open web. Free, no auth.
Search GitHub, npm, PyPI, StackOverflow, ArXiv from one MCP — built for coding agents.