Hirð

Overview Schema Source Related Servers Discussions Admin

Render IR fragment

render_ir_fragment

Read-onlyIdempotent

Render a top-level definition's typed intermediate representation as JSON to reveal desugared bodies, resolved node types, and compiler-generated functions.

Instructions

Render the typed intermediate representation (IR) of one top-level definition as JSON. Use it when the exact lowered structure matters: desugared bodies, the resolved type on every node, a tool's generated function. The IR is verbose and follows the compiler's declaration serialization, so for a human-oriented view prefer get_context_for_symbol or lookup_definition. Returns module, name, and ir (the serialized declaration). An unknown name is not_found with the available names in error.data.available; a type alias is no_ir (aliases are expanded before lowering) with its expansion in error.data.expansion. Read-only: compiles the file's directory in memory (cached until a sibling changes) and writes or executes nothing. Failures are isError results with a stable error.code: file_not_found, read_error, invalid_params, and, for every tool but check_file, parse_error or check_error carrying coded diagnostics in error.data.diagnostics (the shape check_file returns).

Input Schema

TableJSON Schema

Name	Required	Description	Default
`file`	Yes	Path to a .hird source file, absolute or relative to the server's working directory. Every .hird file in its directory is compiled with it as one program, so imported names resolve; answers may name a sibling file.
`name`	Yes	The definition's name, as the file's source would write it: a local definition, a member imported with `use Mod.{name}`, or `Qualifier.name` through `use Mod`.

Output Schema

TableJSON Schema

Name	Required	Description
`ir`	Yes	The declaration, as the compiler serializes its IR.
`file`	Yes
`name`	Yes
`module`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedSep 4, 2026

changedInput schema / properties / file / description

Previous value: -"Path to a .hird source file. Its directory's .hird files are compiled together as one program, so imported names resolve."New value: +"Path to a .hird source file, absolute or relative to the server's working directory. Every .hird file in its directory is compiled with it as one program, so imported names resolve; answers may name a sibling file."

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "file": {
+      "type": "string"
+    },
+    "ir": {
+      "description": "The declaration, as the compiler serializes its IR.",
+      "type": "object"
+    },
+    "module": {
+      "type": "string"
+    },
+    "name": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "file",
+    "ir",
+    "module",
+    "name"
+  ],
+  "type": "object"
+}

Changed2 schema fields changedv0.1.1Aug 28, 2026

changedInput schema / properties / file / description

Previous value: -"Path to a .hird source file."New value: +"Path to a .hird source file. Its directory's .hird files are compiled together as one program, so imported names resolve."

changedInput schema / properties / name / description

Previous value: -"The definition's name."New value: +"The definition's name, as the file's source would write it: a local definition, a member imported with `use Mod.{name}`, or `Qualifier.name` through `use Mod`."

First observedv0.1.0Aug 24, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, but the description adds valuable context: 'Read-only: compiles the file's directory in memory (cached until a sibling changes) and writes or executes nothing.' It also details error codes, error.data shapes, and the stable error.code list, all beyond the annotations. No contradiction exists.

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?

Though long, every sentence carries new information: purpose, use case, alternative tools, output fields, error scenarios, read-only behavior, caching, and error codes. It is front-loaded with purpose and usage, then moves to outputs and failures. Nothing is redundant.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with a rich behavioral and error profile, the description covers when to use, what to expect, error shapes, side-effect guarantees, and alternatives. An output schema exists, so the return type doesn't need full elaboration here. The description is complete for an agent to call it correctly.

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 each parameter has a clear description. The tool description does not add parameter-specific meaning beyond what the schema provides; it only references output and error behavior. With full schema coverage, a baseline of 3 is appropriate.

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 opens with a precise verb-resource pair: 'Render the typed intermediate representation (IR) of one top-level definition as JSON.' It immediately distinguishes itself from human-oriented siblings by naming `get_context_for_symbol` and `lookup_definition` as preferred for human views, so an agent can tell exactly what this tool is for and what it is not.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly states when to use it: 'Use it when the exact lowered structure matters: desugared bodies, the resolved type on every node, a tool's generated function.' It also gives an explicit exclusion: 'for a human-oriented view prefer `get_context_for_symbol` or `lookup_definition`.' This is textbook usage guidance with alternatives and conditions.

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

Deploy Server