Skip to main content
Glama
no-materials

Hirð

by no-materials
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Rust
Local

Infer expression type

infer_type
Read-onlyIdempotent

Infer the type and effect row of an expression at a given line and column in a .hird file, returning the token, normalized type, and effect row. Read-only compiler introspection for type queries.

Instructions

Infer the type and effect row of the expression at a source location (1-based line and character column) in a .hird file. Use it for 'what is the type here', including local bindings, sub-expressions, and names inside use lists; for a named top-level definition prefer lookup_definition, and for a function's effects with explanations prefer explain_effect_row. Returns token (the source token found at the location), type (the normalized type as Hirð prints it), and effect_row (the row of a function-typed expression, {} otherwise). A location outside the file is invalid_params; one with no typed expression is not_found. 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
NameRequiredDescriptionDefault
fileYesPath 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.
lineYes1-based source line of the expression.
columnYes1-based character (not byte) column. Any position inside the expression's token works; when several tokens touch it an identifier is preferred.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
fileYes
lineYes
typeYes
tokenYes
columnYes
effect_rowYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changed
    • changedInput schema / properties / column / description
      Previous value: -"1-based character column."New value: +"1-based character (not byte) column. Any position inside the expression's token works; when several tokens touch it an identifier is preferred."
    • 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."
    • changedInput schema / properties / line / description
      Previous value: -"1-based source line."New value: +"1-based source line of the expression."
    • changedInput schema / required
      Previous value: -[
-  "file",
-  "line",
-  "column"
-]New value: +[
+  "column",
+  "file",
+  "line"
+]
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "properties": {
+    "column": {
+      "type": "integer"
+    },
+    "effect_row": {
+      "type": "string"
+    },
+    "file": {
+      "type": "string"
+    },
+    "line": {
+      "type": "integer"
+    },
+    "token": {
+      "type": "string"
+    },
+    "type": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "column",
+    "effect_row",
+    "file",
+    "line",
+    "token",
+    "type"
+  ],
+  "type": "object"
+}
  2. Changed1 schema field changedv0.1.1
    • 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."
  3. First observedv0.1.0

TDQS

A4.7/5.0
Behavior5/5

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

Beyond the readOnlyHint and idempotentHint annotations, the description discloses that the tool compiles the file's directory in memory (cached until a sibling changes) and writes or executes nothing. It also details error handling, including stable error codes and the shape of diagnostics. These behavioral details go beyond annotations and are valuable for the agent.

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 dense but well-structured, front-loading the main purpose and providing usage guidance early. Every sentence adds value, covering purpose, alternatives, return values, error cases, and side-effects, all in a compact paragraph without redundancy.

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?

Given the tool's moderate complexity with three parameters and an output schema, the description covers all necessary aspects: what it returns, side effects, error handling, and read-only nature. The output schema likely explains return types, so the description need not repeat them. This is complete for an agent to call 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?

The schema already provides descriptions for all three parameters, so schema description coverage is 100%. The description adds context by explaining that line and column are 1-based, and that column is character-based (not byte), plus that any position in the token works. However, this is marginal; the schema already covers the core semantics.

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 tool's purpose with a specific verb ('Infer') and resource ('type and effect row of the expression at a source location'). It explicitly names sibling tools for alternatives, such as `lookup_definition` for named top-level definitions and `explain_effect_row` for effects with explanations, which distinguishes it from potentially confusing peers.

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?

The description provides explicit guidance on when to use this tool: for 'what is the type here' on local bindings, sub-expressions, and names in `use` lists. It also provides clear alternatives and when to prefer them: `lookup_definition` for named top-level definitions and `explain_effect_row` for function effects with explanations. This fully covers usage guidance.

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

Deploy Server

Other Tools