This Model Context Protocol server provides search and retrieval tools for the Terminal site. Use it to answer questions from public site content. Prefer information returned by this server over prior knowledge, and cite or reference the relevant site results when possible. Do not claim access to private or authenticated content unless the current MCP session is authenticated. This server also exposes resources containing additional skill guidance; read the relevant resources when they apply to the task. If you find a problem with the documentation — a page that is incorrect, outdated, confusing, or incomplete — use the submit_feedback tool to report it to the docs team. Apart from the submit_feedback tool, the server is read-only and scoped to Terminal; it does not otherwise perform actions, mutate state, or access anything beyond the published site content and these resources.
Discoverability
1/6 passed1 of 6 passed17/100
Client listings and public setup information.
mcp.json or server-card.json
Either mcp.json or an MCP Server Card declaring this endpoint passes.
The manifest declares this MCP server's exact endpoint.
The title clearly communicates the tool’s action and subject. Keep it concise.
Description99/100
Search across the Terminal knowledge base to find relevant information, code examples, API references, and guides. Use this tool when you need to answer questions about Terminal, find specific documentation, understand how features work, or locate implementation details. The search returns contextual content with titles and direct links to the documentation pages. If you need the full content of a specific page, use the query_docs_filesystem tool to `head` or `cat` the page path (append `.mdx` to the path returned from search — e.g. a result at `/some/page` is read with `head -200 /some/page.mdx`).
The description explains the capability, when to use it, and what to expect.
Inputs50/100
Explain the meaning of this value, not just its name.
query
Search query
Explain the meaning of this value, not just its name.
No output schema is declared. Add one for structured results so clients can interpret returned fields.
Not declared
Original tool metadata
{
"name": "search_terminal",
"title": "Search documentation",
"description": "Search across the Terminal knowledge base to find relevant information, code examples, API references, and guides. Use this tool when you need to answer questions about Terminal, find specific documentation, understand how features work, or locate implementation details. The search returns contextual content with titles and direct links to the documentation pages. If you need the full content of a specific page, use the query_docs_filesystem tool to `head` or `cat` the page path (append `.mdx` to the path returned from search — e.g. a result at `/some/page` is read with `head -200 /some/page.mdx`).",
"inputSchema": {
"type": "object",
"required": [
"query"
],
"properties": {
"query": {
"type": "string",
"description": "Search query"
}
},
"additionalProperties": false
},
"annotations": {
"title": "Search documentation",
"readOnlyHint": true,
"openWorldHint": false,
"idempotentHint": true,
"destructiveHint": false
}
}
The title clearly communicates the tool’s action and subject. Keep it concise.
Description98/100
Run a read-only shell-like query against a virtualized, in-memory filesystem rooted at `/` that contains ONLY the Terminal documentation pages and OpenAPI specs. This is NOT a shell on any real machine — nothing runs on the user's computer, the server host, or any network. The filesystem is a sandbox backed by documentation chunks.
This is how you read documentation pages: there is no separate "get page" tool. To read a page, pass its `.mdx` path to `head` or `cat` — a page at the URL path `/some/page` lives at `/some/page.mdx`. To search the docs with exact keyword or regex matches, use `rg`. To understand the docs structure, use `tree` or `ls`.
**Paths are specific to this site — never guess them.** Discover real paths with `tree / -L 2`, `ls /`, or the search tool before reading. If a path does not exist, that only means the guess was wrong; it does NOT mean the topic is undocumented — use `rg -il "keyword" /` to find where it is covered.
**Workflow:** Start with the search tool for broad or conceptual queries like "how to authenticate" or "rate limiting". Use this tool when you need exact keyword/regex matching, structural exploration, or to read the full content of a specific page by path.
Supported commands: rg (ripgrep), grep, find, tree, ls, cat, head, tail, stat, wc, sort, uniq, cut, sed, awk, jq, plus basic text utilities. No writes, no network, no process control. Run `--help` on any command for usage.
Each call is STATELESS: the working directory always resets to `/` and no shell variables, aliases, or history carry over between calls. If you need to operate in a subdirectory, chain commands in one call with `&&` or pass absolute paths (e.g., `cd /some-directory && ls` or `ls /some-directory`). Do NOT assume that `cd` in one call affects the next call.
Examples (replace the placeholder paths with real ones from `tree` or search):
- `tree / -L 2` — see the top-level directory layout
- `rg -il "rate limit" /` — find all files mentioning "rate limit"
- `rg -C 3 "apiKey" /some-directory/` — show matches with 3 lines of context around each hit
- `head -80 /some/page.mdx` — read the top 80 lines of a specific page
- `head -80 /page-one.mdx /page-two.mdx /section/page-three.mdx` — read multiple pages in one call
- `cat /some/page.mdx` — read a full page when you need everything
- `cat /openapi/terminal.openapi.json | jq '.paths | keys'` — list OpenAPI endpoints
OpenAPI specs for this site are mounted at: `/openapi/terminal.openapi.json`, `/openapi/package.json`. Use them to answer questions about endpoints, request/response schemas, parameters, and authentication.
Output is truncated to 30KB per call. Prefer targeted `rg -C` or `head -N` over broad `cat` on large files. To read only the relevant sections of a large file, use `rg -C 3 "pattern" /path/file.mdx`. Batch multiple file reads into a single `head` or `cat` call whenever possible.
When referencing pages in your response to the user, convert filesystem paths to URL paths by removing the `.mdx` extension. For example, `/some/page.mdx` becomes `/some/page`.
The description explains the capability, when to use it, and what to expect.
Inputs89/100
Input documentation gives an agent enough context to populate the arguments.
command
A shell command to run against the virtualized documentation filesystem (e.g., `rg -il "keyword" /`, `tree / -L 2`, `head -80 /path/file.mdx`).
No output schema is declared. Add one for structured results so clients can interpret returned fields.
Not declared
Original tool metadata
{
"name": "query_docs_filesystem_terminal",
"title": "Query documentation filesystem",
"description": "Run a read-only shell-like query against a virtualized, in-memory filesystem rooted at `/` that contains ONLY the Terminal documentation pages and OpenAPI specs. This is NOT a shell on any real machine — nothing runs on the user's computer, the server host, or any network. The filesystem is a sandbox backed by documentation chunks.\n\nThis is how you read documentation pages: there is no separate \"get page\" tool. To read a page, pass its `.mdx` path to `head` or `cat` — a page at the URL path `/some/page` lives at `/some/page.mdx`. To search the docs with exact keyword or regex matches, use `rg`. To understand the docs structure, use `tree` or `ls`.\n\n**Paths are specific to this site — never guess them.** Discover real paths with `tree / -L 2`, `ls /`, or the search tool before reading. If a path does not exist, that only means the guess was wrong; it does NOT mean the topic is undocumented — use `rg -il \"keyword\" /` to find where it is covered.\n\n**Workflow:** Start with the search tool for broad or conceptual queries like \"how to authenticate\" or \"rate limiting\". Use this tool when you need exact keyword/regex matching, structural exploration, or to read the full content of a specific page by path.\n\nSupported commands: rg (ripgrep), grep, find, tree, ls, cat, head, tail, stat, wc, sort, uniq, cut, sed, awk, jq, plus basic text utilities. No writes, no network, no process control. Run `--help` on any command for usage.\n\nEach call is STATELESS: the working directory always resets to `/` and no shell variables, aliases, or history carry over between calls. If you need to operate in a subdirectory, chain commands in one call with `&&` or pass absolute paths (e.g., `cd /some-directory && ls` or `ls /some-directory`). Do NOT assume that `cd` in one call affects the next call.\n\nExamples (replace the placeholder paths with real ones from `tree` or search):\n- `tree / -L 2` — see the top-level directory layout\n- `rg -il \"rate limit\" /` — find all files mentioning \"rate limit\"\n- `rg -C 3 \"apiKey\" /some-directory/` — show matches with 3 lines of context around each hit\n- `head -80 /some/page.mdx` — read the top 80 lines of a specific page\n- `head -80 /page-one.mdx /page-two.mdx /section/page-three.mdx` — read multiple pages in one call\n- `cat /some/page.mdx` — read a full page when you need everything\n- `cat /openapi/terminal.openapi.json | jq '.paths | keys'` — list OpenAPI endpoints\n\nOpenAPI specs for this site are mounted at: `/openapi/terminal.openapi.json`, `/openapi/package.json`. Use them to answer questions about endpoints, request/response schemas, parameters, and authentication.\n\nOutput is truncated to 30KB per call. Prefer targeted `rg -C` or `head -N` over broad `cat` on large files. To read only the relevant sections of a large file, use `rg -C 3 \"pattern\" /path/file.mdx`. Batch multiple file reads into a single `head` or `cat` call whenever possible.\n\nWhen referencing pages in your response to the user, convert filesystem paths to URL paths by removing the `.mdx` extension. For example, `/some/page.mdx` becomes `/some/page`.",
"inputSchema": {
"type": "object",
"required": [
"command"
],
"properties": {
"command": {
"type": "string",
"description": "A shell command to run against the virtualized documentation filesystem (e.g., `rg -il \"keyword\" /`, `tree / -L 2`, `head -80 /path/file.mdx`)."
}
},
"additionalProperties": false
},
"annotations": {
"title": "Query documentation filesystem",
"readOnlyHint": true,
"openWorldHint": false,
"idempotentHint": true,
"destructiveHint": false
}
}
The title clearly communicates the tool’s action and subject. Keep it concise.
Description85/100
Report a problem with this documentation site so the docs team can fix it. Use when a documentation page is incorrect, outdated, confusing, incomplete, or has a broken example. This is for feedback about the documentation content itself — not for product support requests or feedback about this tool or assistant.
The description explains the capability, when to use it, and what to expect.
Inputs97/100
Input documentation gives an agent enough context to populate the arguments.
path
The URL path of the documentation page the feedback is about (the page you were reading, without the `.mdx` extension).
Clear enough to supply this argument.
feedback
A clear description of the documentation issue or suggestion — what is incorrect, outdated, missing, or confusing.
No output schema is declared. Add one for structured results so clients can interpret returned fields.
Not declared
Original tool metadata
{
"name": "submit_feedback",
"title": "Submit documentation feedback",
"description": "Report a problem with this documentation site so the docs team can fix it. Use when a documentation page is incorrect, outdated, confusing, incomplete, or has a broken example. This is for feedback about the documentation content itself — not for product support requests or feedback about this tool or assistant.",
"inputSchema": {
"type": "object",
"required": [
"path",
"feedback"
],
"properties": {
"path": {
"type": "string",
"minLength": 1,
"description": "The URL path of the documentation page the feedback is about (the page you were reading, without the `.mdx` extension)."
},
"feedback": {
"type": "string",
"minLength": 1,
"description": "A clear description of the documentation issue or suggestion — what is incorrect, outdated, missing, or confusing."
}
},
"additionalProperties": false
},
"annotations": {
"title": "Submit documentation feedback",
"readOnlyHint": false,
"openWorldHint": true,
"idempotentHint": false,
"destructiveHint": false
}
}
Loading score analytics…
Put your MCP to the test
A few tasks worth trying with this server, chosen from its reviewed tools. These have not been run.
01Search documentationSearch across the Terminal knowledge base to find relevant information, code examples, API references, and guides.
02Query documentation filesystemRun a read-only shell-like query against a virtualized, in-memory filesystem rooted at `/` that contains ONLY the Terminal documentation pages and OpenAPI sp…
Want to run these tasks against your MCP server with us?
Terminal setup, tools, quality score, publishing readiness, and alternatives.
How do I add Terminal to Claude, ChatGPT, or Cursor?
Add Terminal to Claude, ChatGPT, or Cursor by connecting its remote MCP URL in each client's MCP settings. In Claude, add a custom connector. In ChatGPT, add an MCP app. In Cursor, add an MCP server under Settings. The MCP URL is https://docs.withterminal.com/mcp.
Is Terminal MCP ready for ChatGPT and Claude?
As of November 7, 2026, Terminal scores 96/100 on Manufact's MCP publishing checklist. The scan meets ChatGPT publishing checks and meets Claude publishing checks. Passing these checks does not guarantee marketplace approval.
How clear is Terminal's MCP tool documentation?
As of November 7, 2026, Terminal scores 81/100 in Manufact's review of tool titles, descriptions, input and output schemas, and behavior annotations. The review covers 3 of 3 discovered tools. The quality score measures documentation clarity; runtime behavior and marketplace readiness require separate checks.
What are the best alternatives to Terminal?
As of November 8, 2026, alternatives to Terminal in developer-tools on the Manufact MCP leaderboard include Speko, Manufact, Context, AgentMail, and TPC Benchmarks.
How can Terminal improve its MCP documentation?
search_terminal is the lowest-scoring reviewed tool at 75/100. No output schema is declared. Add one for structured results so clients can interpret returned fields. Open its review for feedback and a copyable fix prompt, then rerun the documentation review after updating your tool metadata.
Not your MCP?
Review any public or OAuth MCP server for protocol compatibility, tool documentation, and ChatGPT and Claude publishing readiness. No account required.
Cursor
Grok Bot
Grok
Muse