MCP Example Workflows

Paste one of these prompts into any client connected to the MIND MCP server. Under each prompt is the order of tool calls a model usually makes for it, and what the answer should contain. A model may choose another order; every tool only reads, so nothing runs that changes your project.

Write a new MIND program

Write a MIND function that multiplies a [B, 784] input tensor by a [784, 10]
weight tensor and adds a [10] bias, with the shapes checked at compile time.
Use the MIND MCP server to check every std function and cite the docs you used.

What happens:

  1. search for tensor types, symbolic dimensions and matrix multiplication.
  2. fetch of the pages the best passages come from, or of guide/llms-full for the whole language.
  3. lookup_symbol for each std function the code calls, to copy its exact signature.

Result: the code, with a link to each docs page it relied on. For a shorter start, run the write_mind_code prompt with the task; it attaches the whole language reference up front.

Fix a compiler error

mindc fails on my file with this output:

```
error[parse][E1001]: unexpected `)`, expected an expression
```

Explain the error with the MIND MCP server and fix my code:

<paste the file here>

What happens:

  1. explain_error with code: "E1001": the phase (parse), what the code means and the pages that document it.
  2. fetch of a cited page, or a read of mind://errors/E1001, for the full reference.
  3. The fix, applied to the code you pasted.

Result: what went wrong, the corrected code, and the error-reference links. The explain_mind_error prompt does the same from a slash command: pass the code and the compiler output.

Find the right std function

Which MIND standard-library function returns the length of a string, and what
is its exact signature? Check it with the MIND MCP server.

What happens:

  1. lookup_symbol with a partial name, such as name: "len" and module: "string". Partial names match by prefix, then by substring, then by spelling distance.
  2. A read of the mind://std/string resource the result links to, when the model wants the whole module.

Result: pub fn string_len(s: String) -> i64, with its doc comment ("current byte length (NOT codepoint count)") and a link to the line in the release source.

Port code from another language

Port this NumPy function to MIND. Read the MIND migration guide through the MIND
MCP server and confirm every API you use with search and lookup_symbol.

def predict(x, w, b):
    return np.maximum(x @ w + b, 0)

What happens:

  1. fetch of docs/migration, the migration guide from PyTorch to MIND.
  2. search and lookup_symbol for each operation the port needs (matrix multiply, add, element-wise maximum).
  3. The MIND version, with static shapes in the signature.

Result: the ported function and the pages that back each API it uses. The port_to_mind prompt takes python, numpy, pytorch, jax, rust, c or cpp and attaches the migration guide and the language reference for you.

Read a long spec chapter

List the chapters of the MIND Core v1 specification, then read the whole
autodiff chapter and summarize its derivative rules.

What happens:

  1. list_docs with source: "spec": every chapter with its id and section headings.
  2. fetch with id: "spec/autodiff".
  3. While metadata.next_offset is a number, fetch again with offset set to it.

Result: a summary of the chapter, citing its URL in the specification repository.

Check what changed in a release

What changed in mindc 0.10.2? Cite the release notes.

What happens:

  1. search with source: "changelog". A release number in the query puts that release's notes first.
  2. A read of mind://changelog/0.10.2 for the whole section, when the passages are not enough.

Result: the changes in that release, each with a link to its line in the changelog.