Skip to main content
Glama
fxckcode

tauri-docs-mcp

by fxckcode
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

tauri-docs-mcp

npm version

A read-only Model Context Protocol (MCP) server for resolving and querying a checked-in snapshot of official Tauri 2 documentation.

Requirements

  • Node.js 20.19 or newer (supported Node LTS)

  • npm 10 or newer

The committed package-lock.json is authoritative. Use npm install for local development and dependency changes; CI and reproducible installs use npm ci. Lockfile changes must be committed with dependency changes.

Related MCP server: mcp-docs-server

Install and run

Install the published package:

npm install --global tauri-docs-mcp

Or install it in a project and invoke the binary from node_modules/.bin:

npm install tauri-docs-mcp
npx tauri-docs-mcp

Build from a checkout, then run the compiled stdio server:

npm install
npm run build
node dist/src/index.js

Configure an MCP client to launch the installed binary over stdio:

{
  "mcpServers": {
    "tauri-docs": {
      "command": "tauri-docs-mcp"
    }
  }
}

Portable configurations for generic MCP clients, Claude Desktop, Cursor, and VS Code are in examples/mcp/. They pin the package version and use stdio only. Installable agent guidance is in skills/tauri-docs-mcp/SKILL.md.

The server writes MCP JSON-RPC messages only to stdout. It does not start an HTTP listener. Diagnostics are disabled by default; opt in with TAURI_DOCS_MCP_DIAGNOSTICS=1 and they are written to stderr as event names only (never request arguments, corpus content, secrets, or PII).

Tool contract

The server exposes two stable tools and one backwards-compatible legacy tool.

resolve_tauri_docs

Resolve the default snapshot or an explicit identifier:

{}
{ "identifier": "tauri@2" }

Supported identifiers are tauri, tauri@2, and the immutable snapshot ID tauri-2@58194ceb69424c4332b2780b196ced3a6fffb32b. Resolution is deterministic and returns snapshot, source revision, generated-at, version, and entry-count metadata. Unsupported identifiers return UNSUPPORTED_SNAPSHOT.

query_tauri_docs

Query content from the default or selected snapshot:

{ "query": "capabilities", "snapshot": "tauri@2", "limit": 3 }

query is required and must contain 1–200 non-whitespace characters and at most 16 whitespace-separated terms. snapshot is optional and accepts the resolver identifiers. limit is an optional integer from 1–10 (default 5). Results are bounded, deterministic, and include title, heading, section, canonical URL, content, corpus snapshot, source revision, Tauri version, and versionSensitive. Empty matches return results: [], not an application error. Inputs reject unknown fields.

Both tools are read-only and idempotent. They read only the checked-in corpus; there is no live fetching or arbitrary URL access.

Resource and lifecycle bounds

The shared tool contract enforces a 200-character query, 16 terms, 10 results, 1,200-character snippets, 8 KiB corpus entries, and 32 KiB serialized tool responses. The stdio frame buffer is capped at 64 KiB. EOF, transport errors, SIGINT, and SIGTERM share an idempotent shutdown path with a one-second cleanup bound; in-flight work is allowed to settle or is abandoned at that bound.

search_tauri_docs (compatibility)

Existing clients can continue to call:

{ "query": "capabilities", "limit": 3 }

It remains supported with its existing response shape and limits. New clients should use resolve_tauri_docs followed by query_tauri_docs.

Application errors are returned with stable discriminated codes such as INVALID_INPUT, INVALID_QUERY, INVALID_LIMIT, and UNSUPPORTED_SNAPSHOT; protocol errors remain MCP protocol errors.

Product boundary

This package is intentionally:

  • read-only;

  • stdio-only;

  • limited to its checked-in corpus; and

  • constrained to official Tauri 2 sources under https://v2.tauri.app/.

It never fetches user-controlled URLs, writes files, executes arbitrary code, controls a Tauri runtime, provides hosted HTTP, authenticates users, or emits telemetry. See docs/architecture.md for the module seams.

Development commands

npm install          # install from package-lock.json
npm run typecheck    # TypeScript validation
npm run build        # compile runtime files to dist/
npm test             # run the full Vitest suite
npm run lint         # ESLint
npm run format       # format tracked source and documentation
npm run format:check # verify formatting without writing
npm pack --dry-run   # inspect the publish allowlist
npm run package:smoke -- /path/to/tauri-docs-mcp-0.1.0.tgz # test a packed install

The pull-request workflow runs the same commands from a clean checkout. To reproduce its package step locally, create a tarball and pass its path to the smoke test:

mkdir -p .tmp/package
TARBALL=$(npm pack --json --pack-destination .tmp/package | node -e "let s=''; process.stdin.on('data', d => s += d).on('end', () => process.stdout.write(JSON.parse(s)[0].filename))")
npm run package:smoke -- ".tmp/package/$TARBALL"
rm -rf .tmp

See CONTRIBUTING.md for contribution rules and SUPPORT.md for supported use cases. Report vulnerabilities privately as described in SECURITY.md.

Releases and registry

The release workflow runs from a version tag and checks package, immutable corpus metadata, registry metadata, and the pack allowlist before publishing. npm publishing uses provenance/trusted publishing where enabled, then runs a fresh published-package smoke gate. Official MCP Registry publication is a separately protected environment chained after the successful npm job. No release is published from pull requests. See CHANGELOG.md for the release and MCP contract-change process.

Corpus maintenance

The runtime reads only the checked-in generated snapshot under corpus/; it never fetches documentation URLs. The approved manifest records canonical URLs, section hierarchy, Tauri version, source revision/freshness metadata, and a SHA-256 hash for each concise excerpt. The source revision is immutable, so a future snapshot must use a new tauri-2@<revision> directory.

After an approved source review, regenerate and validate deterministically:

npm run ingest:docs
npm run validate:corpus

validate:corpus fails if the manifest is unsafe or incomplete, if content hashes drift, or if the generated artifact differs from its manifest. Source and license attribution is preserved in corpus/NOTICES.md.

Sources

Available Tools

3 tools
query_tauri_docsQuery Tauri documentationB
Read-onlyIdempotent

Query bounded content from a selected or default checked-in Tauri documentation snapshot.

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum results; defaults to 5.
queryYesSearch terms, bounded by length and term count.
snapshotNoOptional supported snapshot identifier.

TDQS

B3.3/5.0
Behavior3/5

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

Annotations already establish readOnly, idempotent, and non-destructive behavior. The description adds that content comes from a selected or default checked-in snapshot and is bounded, but it does not cover return format, pagination, or auth requirements beyond the annotation baseline.

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?

A single front-loaded sentence with no filler. Every phrase contributes to the tool's purpose and scope.

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 read-only annotations, full schema descriptions, and no output schema, the definition is minimally adequate for invocation. However, it does not help an agent distinguish this tool from its similarly named siblings, which is the main contextual gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents query, limit, and snapshot. The description only hints at default snapshot behavior and bounded querying, adding marginal meaning beyond the structured parameter definitions.

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 gives a specific verb (query) and resource (Tauri documentation snapshot content), but does not differentiate the tool from its siblings resolve_tauri_docs and search_tauri_docs. 'Bounded content from a selected or default checked-in snapshot' is clear yet slightly abstract.

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 offers no explicit when-to-use guidance and does not mention when to choose this tool over resolve_tauri_docs or search_tauri_docs. Only the implicit querying context is provided.

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

resolve_tauri_docsResolve Tauri documentation snapshotB
Read-onlyIdempotent

Resolve a Tauri documentation identifier to deterministic metadata from the checked-in corpus.

ParametersJSON Schema
NameRequiredDescriptionDefault
identifierNotauri, tauri@2, or an immutable snapshot identifier.

TDQS

B3.3/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds useful context that results come from a checked-in corpus and are deterministic (i.e., offline, stable), but says nothing about failure behavior for unknown identifiers.

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?

A single front-loaded sentence with no filler; the verb and resource arrive in the first few words. Nothing to trim.

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 one-parameter read tool this is nearly sufficient, but there is no output schema and the description never characterizes the returned 'metadata', leaving an agent unsure what the resolution yields. The identifier-to-metadata contract is the tool's whole purpose and remains underspecified.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the schema itself already provides example forms ('tauri, tauri@2, or an immutable snapshot identifier'). The description adds no syntax or format detail beyond what the schema supplies, so the baseline 3 applies.

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?

Names a specific verb (resolve) and resource (Tauri documentation identifier), and the phrase 'deterministic metadata from the checked-in corpus' distinguishes it from a search tool. However, it never explicitly contrasts itself with its siblings query_tauri_docs and search_tauri_docs, and 'metadata' remains undefined.

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?

There is no statement of when to use this tool rather than the sibling search/query tools, nor any prerequisites or exclusion conditions. An agent must infer that a known identifier should be routed here instead of to search_tauri_docs.

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

search_tauri_docsSearch Tauri documentation (compatibility)A
Read-onlyIdempotent

Compatibility search path. Prefer resolve_tauri_docs followed by query_tauri_docs.

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum results, from 1 to 10; defaults to 5.
queryYesSearch terms, 1-200 characters.

TDQS

A3.8/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds that this is a compatibility path, implying legacy or fallback status, but does not mention auth requirements, rate limits, or other operational 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?

Two short sentences with zero wasted words. The compatibility status is front-loaded, and the preferred alternative workflow follows immediately.

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 search tool with full schema coverage and annotations covering safety, the description gives the essential routing context. It could be clearer about exactly when this compatibility path is still required, but no output schema means return values need not be explained.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so both query and limit are fully documented in the input schema. The description adds no additional parameter-level meaning, making the baseline score of 3 appropriate.

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 labels this a 'Compatibility search path' and names the preferred sibling workflow, so an agent can distinguish it from resolve_tauri_docs and query_tauri_docs. However, the description itself never states the explicit verb 'search' or the resource 'Tauri documentation'—that comes from the title—making it clear but slightly reliant on surrounding metadata.

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 explicitly tells the agent to prefer resolve_tauri_docs followed by query_tauri_docs, which is strong alternative routing. It stops short of stating the exact condition under which this compatibility path should still be chosen, leaving the fallback threshold implicit.

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.

  1. 3 tool updatesv0.2.0
    • Addedquery_tauri_docs
    • Addedresolve_tauri_docs
    • Changedsearch_tauri_docs1 field changed
      • addedInput schema / properties / query / maxTerms
        Added value: +16
  2. 1 tool updatev0.1.0
    • First observedsearch_tauri_docs
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.7/5.0

Scored across 3 tools

Disambiguation4/5

resolve_tauri_docs (metadata lookup) and query_tauri_docs (content retrieval) are clearly distinct purposes, and search_tauri_docs is explicitly documented as a compatibility alias for the resolve+query pair. The remaining ambiguity is that an agent might still reach for search, but the description steers it correctly.

Naming Consistency5/5

All three tools follow an identical verb_noun_topic pattern (resolve/query/search + _tauri_docs) in consistent snake_case. The naming is fully predictable.

Tool Count4/5

Three tools is slightly thin but appropriate for a documentation lookup server with a small bounded domain. Each tool covers a distinct retrieval phase with no filler.

Completeness4/5

The resolve-then-query lifecycle plus a compatibility search covers discovery and content retrieval for the Tauri doc corpus. A browse/list-all-identifiers operation is absent, but search largely covers that need.

Maintenance

ActivityMaintained
ResponsivenessResponsive

Resources

Related MCP Connectors

Related MCP Servers