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., "@jev-docs-mcp how do I use the Noul primitive in Jev?"
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 that lets AI coding agents (Cursor, Claude Code, Codex, and other MCP clients) search and read the official TypeSafe Jev documentation.
It loads the docs from docs.typesafe.ai/llms.txt and docs.typesafe.ai/llms-full.txt and caches them in memory for an hour. No API key is needed.
Tool | What it does |
| Lists every docs page with its path and a one-line summary. |
| Full-text search across all pages; returns the best matches with snippets. |
| Returns a full page by path ( |
Related MCP server: MCP Framework Documentation Server
Requires Node.js 18 or newer. Nothing to install: npx downloads and runs the package.
Add this to ~/.cursor/mcp.json (or .cursor/mcp.json in a project):
{
"mcpServers": {
"jev-docs": {
"command": "npx",
"args": ["-y", "jev-docs-mcp"]
}
}
}Then open Cursor Settings → Tools & MCP and make sure jev-docs is enabled.
claude mcp add jev-docs -- npx -y jev-docs-mcpRun npx -y jev-docs-mcp as a stdio server.
git clone https://github.com/mohit716/jev-docs-mcp.git
cd jev-docs-mcp
npm install
npm testThis starts the server, calls each tool against the live docs, and prints the results.
This is an independent project. The documentation content belongs to TypeSafe AI.
List every page in the official TypeSafe/Jev documentation (docs.typesafe.ai) with its path and one-line summary. Use this to discover what exists before reading.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, so safety is covered. The description adds genuinely useful behavioral context that no structured field provides: it returns every page (no filtering) with path and one-line summary, which compensates for the absent output schema. It says nothing about result size or pagination.
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 sentences, zero filler, with the return contract front-loaded before the usage hint. Every clause earns its place.
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 parameterless read-only listing tool with annotation-covered safety, the description is nearly complete: it states scope, source, and return fields despite there being no output schema. Only minor operational details (result size, pagination, freshness) are missing.
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 tool takes zero parameters, so there is nothing for the description to disambiguate beyond what the empty schema shows. Baseline 4 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?
States a specific verb (List) and resource (every page in the TypeSafe/Jev docs), names the source domain (docs.typesafe.ai), and specifies the return shape (path + one-line summary). An agent can immediately distinguish this full-listing tool from the search and read siblings.
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?
"Use this to discover what exists before reading" gives a clear condition for selecting this tool over jev_docs_read. It does not explicitly contrast with jev_docs_search or say when not to use it, so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the full Markdown of one Jev documentation page. Accepts a path (e.g. 'primitives/noul'), a docs.typesafe.ai URL, or an exact page title. Long pages are paginated with offset.
| Name | Required | Description | Default |
|---|---|---|---|
| page | Yes | Page path, URL, or title | |
| offset | No | Character offset to start from, for long pages | |
| max_chars | No | Maximum characters to return |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds real behavioral context the annotations do not: long pages are paginated and require an offset, and it discloses the three input forms accepted for a page reference.
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 short sentences, zero filler, with the core action front-loaded and input forms and pagination following in order of importance.
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 read-only, no-output-schema tool, the description covers the action, all accepted page-reference forms, and pagination behavior. Nothing an agent needs in order to invoke it correctly is missing.
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 baseline is 3, but the description goes beyond the schema by giving a concrete path example ('primitives/noul') and by tying the offset parameter to its purpose (pagination of long pages). That adds usable format guidance not present in the schema text.
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 and resource ('Read the full Markdown of one Jev documentation page') and the singular scope plus 'full Markdown' implicitly separates it from jev_docs_list and jev_docs_search. It stops short of naming those siblings explicitly, so the differentiation is inferable rather than stated.
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 explains the accepted input forms but gives no when-to-use or when-not-to-use guidance, and does not route the agent to jev_docs_search or jev_docs_list for finding an unknown page. Usage is implied (read a page once you know its path/title) rather than spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full-text search across the official TypeSafe/Jev documentation. Returns the best-matching pages with paths and snippets; pass a path to jev_docs_read for the full page.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results | |
| query | Yes | Search terms, e.g. 'noul confidence threshold' or 'python sdk async' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, so safety and scope are covered. The description adds context annotations cannot express: the return shape (best-matching pages with paths and snippets) and the intended handoff to jev_docs_read. It omits ranking behavior and rate limits, so not a 5.
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 sentences with zero filler; the purpose is front-loaded and the workflow hint follows immediately. Every clause earns its place.
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?
There is no output schema, yet the description explicitly describes what comes back (matching pages with paths and snippets) and what to do next. Combined with full schema coverage on both parameters, an agent has everything needed to call and follow up correctly.
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% and the query param even carries example search phrases, so the schema does the heavy lifting. The description adds no syntax, matching, or query-construction guidance beyond what the schema already states, making the baseline 3 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?
States a specific verb and resource ('Full-text search across the official TypeSafe/Jev documentation'), which cleanly separates it from the sibling list and read tools. An agent can identify it as the retrieval/finding step without opening any schema.
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 second sentence gives explicit routing guidance: results come back as paths and snippets, and a path should be passed to jev_docs_read for the full page. It names the downstream alternative but does not state when to prefer jev_docs_list or when search is inappropriate.
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.
v1.0.0jev_docs_listjev_docs_readjev_docs_searchScored across 3 tools
Each tool has a clearly distinct purpose: list enumerates all pages, search performs full-text lookup, and read fetches full page content. The descriptions explicitly clarify how they differ, leaving no realistic ambiguity.
All three tools follow the same predictable pattern: jev_docs_ prefix plus a consistent verb (list, search, read). There is no mixing of conventions.
Three tools is a well-scoped minimal set for a documentation server: discover, search, and read. Each tool earns its place without redundancy.
The surface covers the full read-only documentation lifecycle: discovery via list, targeted lookup via search, and full content retrieval via read with pagination support. No obvious gaps remain.
An MCP server that gives your AI access to the source code and docs of all public github repos
MCP server for agentverse documentation, generated by doc2mcp.
Augments MCP Server - A comprehensive framework documentation provider for Claude Code
Team docs served to AI agents over MCP - search, Markdown reads, version pinning, read audit.
