MCP Tools Reference

The MIND MCP server has five tools, and none of them changes anything. Each one carries these annotations, so a client that asks before running a tool that writes can run them without asking:

{
  "readOnlyHint": true,
  "destructiveHint": false,
  "idempotentHint": true,
  "openWorldHint": false
}

Each tool returns structuredContent that matches its output schema, and the same JSON as the first text block for clients that read only text. A result is never longer than 64,000 characters (see Limits and Errors).

Search MIND docs

Tool search. Searches the documentation, the standard library, the error reference, the specification and the examples, and returns ranked passages, each with a citation URL.

Output, from a real call (the passage text is shortened here):

{
  "results": [
    {
      "id": "docs/determinism#1-integer-semantics-",
      "title": "The Determinism Contract",
      "url": "https://mindlang.dev/docs/determinism#1-integer-semantics-",
      "text": "Fully deterministic and byte-identical across substrates. …",
      "section": "1. Integer semantics — Shipped",
      "source": "docs",
      "score": 0.97
    }
  ],
  "mode": "lexical",
  "truncated": true,
  "index": "7f889553ec65"
}

• results: the passages, best first. section is present when the passage sits under a heading; source is docs, guide, std, errors, examples, spec or changelog; score only orders the results.
• mode: how the passages were ranked. hybrid when matching by meaning was combined with matching by keyword; lexical when keywords alone ranked them.
• truncated: true when passages were left out to stay within max_tokens.
• index: the build id of the index, the same one mind://about shows.
• note: present only when nothing matched, with what to try next.

Search matches by meaning and by keyword (mode: "hybrid"). When the embedding model is unavailable, or one client has sent more than 30 searches in the last minute, it matches by keyword alone instead of failing (mode: "lexical"). Read mode rather than assuming either one. The semantic flag in mind://about and server/discover says only that the index holds the data for ranking by meaning, not how a search was ranked. A release number in the query (0.10.2) brings that release's notes to the top. Cite the url of each passage you use.

Example prompts:

• "How do I declare a tensor with a symbolic batch dimension in MIND? Use the MIND docs."
• "What does integer division by zero return in MIND?"
• "Search the MIND specification for how broadcasting is defined."

Read a MIND doc

Tool fetch. Returns the full text of one document by id, docs path or mindlang.dev URL. Long documents come in pages.

Output, from a real call with max_chars: 1000 (the text is shortened here):

{
  "id": "docs/determinism",
  "title": "The Determinism Contract",
  "text": "# The Determinism Contract\n\nThe MIND determinism contract: …",
  "url": "https://mindlang.dev/docs/determinism",
  "metadata": {
    "source": "docs",
    "version": "mindc 0.10.2",
    "last_modified": "2026-10-08",
    "offset": 0,
    "next_offset": 1000,
    "total_chars": 16309
  }
}

To read a long document, call fetch again with offset set to metadata.next_offset until next_offset is null. If a page would go over the 64,000-character result cap once encoded as JSON, fetch returns a shorter page and next_offset points at the rest. An id with a section anchor (docs/determinism#1-integer-semantics-) returns the whole document, and url keeps the anchor.

An id that names no document, a URL that is not a mindlang.dev docs page, or an offset past the end returns an error result that says what to use instead.

Example prompts:

• "Read the whole MIND determinism contract and list what it marks as non-deterministic."
• "Fetch https://mindlang.dev/docs/shapes and summarize the broadcasting rules."

List MIND docs

Tool list_docs. Lists the documents with their ids, URLs, one-line descriptions and section headings, to choose what to fetch.

Output, from a real call with no arguments (two of the 44 items are shown):

{
  "items": [
    {
      "id": "guide/llms-full",
      "title": "MIND reference for AI agents",
      "url": "https://mindlang.dev/llms-full.txt",
      "description": "The language, compiler and toolchain in one page."
    },
    {
      "id": "docs/index",
      "title": "MIND Language Documentation",
      "url": "https://mindlang.dev/docs",
      "description": "MIND documentation: the language, the deterministic compiler, canonical mic@3 IR, evidence chains, autodiff, the standard library and toolchain guides.",
      "sections": ["Start here", "Core Concepts", "Full-Stack AI (Roadmap)", "Language Specification", "Getting Help"]
    },
    …
  ],
  "total": 44
}

• guide/llms-full, the whole language on one page, is always listed first.
• sections holds the document's second-level headings.
• With source: "all", descriptions are cut to 100 characters and sections is left out, to keep the list short. The per-code error documents are not listed; use explain_error for them.

Example prompts:

• "List the MIND specification chapters, then read the one about autodiff."
• "Which example programs ship with the current MIND release?"

Look up a MIND std symbol

Tool lookup_symbol. Finds standard-library functions, types and modules by exact or partial name, and returns their signatures and doc comments from the current release.

Matching ignores case and tries, in order: the exact name, names that start with it, names that contain it, and names within two edits of it. It returns the first of these that finds anything, and match says which one (exact, prefix, substring, fuzzy, or none). Functions come before types and modules, shorter names first. std.string.string_len, string::string_len and string_len() all mean string_len in module string; std.string alone means the module.

Output, from a real call with name: "string::string_len":

{
  "matches": [
    {
      "kind": "function",
      "name": "string_len",
      "module": "string",
      "signature": "pub fn string_len(s: String) -> i64",
      "doc": "string_len — current byte length (NOT codepoint count).",
      "url": "https://github.com/star-ga/mind/blob/v0.10.2/std/string.mind#L31"
    }
  ],
  "match": "exact",
  "version": "mindc 0.10.2"
}

After the JSON, the result links up to three matched modules as resource_link blocks (mind://std/string), so a client can attach the whole module. Signatures come from the mindc release named in version. When nothing matches, matches is empty, match is none, and a short hint follows.

Example prompts:

• "What is the exact signature of string_len in MIND?"
• "Which MIND std functions start with vec_?"
• "Look up sha256 in the MIND standard library and show how to call it."

Explain a MIND compiler error

Tool explain_error. Explains an error code: the pipeline phase that raises it, what it means, and the documentation that covers it.

Output, from a real call with code: "E2103":

{
  "code": "E2103",
  "phase": "Type-check (E2xxx): type mismatches, inference failures, shape validation",
  "title": "Matmul inner-dimension mismatches",
  "summary": "mindc 0.10.2 docs: Matmul inner-dimension mismatches. Shape validation for Core v1 operators is surfaced during type checking, inside the E2xxx space.",
  "documented": true,
  "sources": [
    { "title": "Error Handling › Error Codes", "url": "https://mindlang.dev/docs/errors#error-codes" },
    { "title": "MIND Core Error Model (mindc 0.10.2)", "url": "https://github.com/star-ga/mind/blob/v0.10.2/docs/errors.md#error-codes" }
  ]
}

• documented is false when the references describe only the code's phase, not the code itself. title is then left out and summary describes the phase.
• summary quotes the current compiler's docs first, then the Core v1 specification where it gives the code a different meaning.
• A documented code also gets a resource_link to mind://errors/<CODE>, which holds every public reference for it.

The first digit of a code names its phase:

E1xxx to E5xxx follow mindc's own numbering, documented under Errors. The Core v1 specification numbers E3xxx to E5xxx differently; explain_error names a code the way mindc reports it and adds the specification's meaning after it.

Example prompts:

• "My MIND build fails with E2103. What does it mean and how do I fix it?"
• "Explain MIND compiler error E1001 and show the docs it comes from."

Errors returned as results

Problems the model can fix come back as a normal tool result with isError: true, so the model reads the message and tries again:

• Arguments that do not match the input schema: the text starts with Input validation error: and names the argument, for example #/limit: 99 is greater than 20.
• An unknown fetch id, an offset past the end of a document, or a result over 64,000 characters: the text says what to ask for instead.

A tool name the server does not have is a JSON-RPC error (-32602), not a result. Limits and Errors lists every code.

Earlier tool names

Related pages

• MCP Server: set the server up in your client
• Resources and Prompts: documents to attach and ready-made prompts
• Example Workflows: which tools a task calls, in order
• Limits and Errors: rate limits, sizes and error codes