Skip to main content
Glama
dpdanpittman

mcp-server-quint

by dpdanpittman

quint_parse

Parse Quint specification code to generate JSON-formatted intermediate representation for AST inspection and error detection.

Instructions

Parse a Quint spec and return the intermediate representation (IR) as JSON. Useful for inspecting the AST or checking for parse errors.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sourceNoQuint specification source code (.qnt content)
file_pathNoPath to a .qnt file on disk

Implementation Reference

  • The implementation of the 'quint_parse' tool, which takes a source string and file path, runs the quint parse command, and returns the resulting IR JSON.
    server.tool(
      "quint_parse",
      "Parse a Quint spec and return the intermediate representation (IR) as JSON. Useful for inspecting the AST or checking for parse errors.",
      sourceSchema,
      async ({ source, file_path }) => {
        try {
          const outFile = join(
            tmpdir(),
            `quint_ir_${randomBytes(8).toString("hex")}.json`,
          );
          const result = await runWithSource(source, file_path, (f) => [
            "parse",
            `--out=${outFile}`,
            f,
          ]);
    
          if (result.ok) {
            try {
              const ir = await readFile(outFile, "utf-8");
              await unlink(outFile).catch(() => {});
              return { content: [{ type: "text", text: ir }] };
            } catch {
              return formatResult(result);
            }
          }
    
          await unlink(outFile).catch(() => {});
          return formatResult(result);
        } catch (err) {
          return {
            content: [{ type: "text", text: `Error: ${err.message}` }],
            isError: true,
          };
        }
      },
    );
Behavior3/5

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

With no annotations provided, the description carries the full burden. It discloses that the tool parses and returns IR as JSON, which is useful, but lacks details on error handling (e.g., how parse errors are reported), performance (e.g., rate limits), or prerequisites (e.g., valid Quint syntax). It does not contradict annotations, but more behavioral context would be helpful.

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?

The description is two sentences, front-loaded with the core purpose and followed by a specific use case. Every sentence adds value without redundancy, making it efficient and easy to understand quickly.

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 tool's moderate complexity (parsing with two parameters) and no output schema, the description is adequate but incomplete. It explains the purpose and use case but lacks details on output format (e.g., structure of the JSON IR) and error behavior, which would be important for an AI agent to invoke it correctly without structured output guidance.

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?

The schema description coverage is 100%, so the schema already documents both parameters (source and file_path). The description does not add any meaning beyond this, such as explaining the relationship between source and file_path (e.g., if one overrides the other) or usage examples. Baseline 3 is appropriate as the schema handles parameter documentation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the specific action ('Parse a Quint spec') and the resource ('Quint spec'), distinguishing it from siblings by specifying it returns the intermediate representation (IR) as JSON for inspecting AST or checking parse errors. This differentiates it from tools like quint_run or quint_test that likely execute or test specifications rather than parse them.

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?

The description provides clear context on when to use this tool ('Useful for inspecting the AST or checking for parse errors'), which implies it's for analysis rather than execution. However, it does not explicitly state when not to use it or name alternatives among siblings, such as quint_typecheck for type-related analysis.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/dpdanpittman/mcp-server-quint'

If you have feedback or need assistance with the MCP directory API, please join our Discord server