Skip to main content
Glama

Outline module

list_definitions
Read-onlyIdempotent

List a .hird module's top-level bindings and imports in source order to orient yourself before pulling up a symbol's context.

Instructions

Outline a .hird module: every name its top-level declarations bind, in source order, plus its imports. Use it to orient in a module before choosing which symbols to pull in with get_context_for_symbol; it is cheap (no bodies, no effect graph) and the only tool that names a module's symbols without a failed lookup. Returns module, imports (each with the imported module as written, its defining file, the qualifier a whole-module import binds or null, and the members a selective import binds unqualified), and definitions, each with name, kind (the kinds lookup_definition reports: a type also lists each constructor, a tool its generated tool_function, an actor its message_type and each message_constructor), line, a one-line signature, nullable doc, and approx_tokens (the signature's estimated cost at ~4 characters per token, so a get_context_for_symbol budget of at least that keeps the signature whole). 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.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
fileYes
moduleYes
importsYes
definitionsYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.4.0

TDQS

A4.9/5.0
Behavior5/5

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

The annotations already declare readOnly, idempotent, and non-destructive. The description goes beyond that by disclosing that the tool compiles the file's directory in memory (cached until a sibling changes) and runs no side effects, and by giving a full list of stable error codes and diagnostic shapes. No contradiction exists; the description adds valuable behavioral context the annotations do not cover.

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 longer than average, but every sentence carries a distinct fact: purpose, use case, return structure, behavior, and error handling. It is front-loaded with the core purpose and usage guidance before diving into output details, with no filler or tautology.

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 is a small, read-only helper, the description is complete. It explains the return shape, the semantics of each field, the caching behavior, and all possible error codes. An agent has all the information needed to invoke the tool correctly and interpret its results.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema fully covers the sole `file` parameter (path resolution, relative/absolute, compilation of a directory, import resolution). The description adds the caching detail and reinforces the read-only nature, but it does not fundamentally alter the parameter's meaning. With 100% schema coverage, the baseline is 3; the cache and error behavior are a small yet useful bonus.

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 begins with a specific verb and resource: 'Outline a .hird module: every name its top-level declarations bind, in source order, plus its imports.' It explicitly distinguishes itself from siblings by stating it is 'the only tool that names a module's symbols without a failed lookup' and referencing `get_context_for_symbol` as the follow-up, making it impossible to confuse with other tools.

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 provides explicit guidance: 'Use it to orient in a module before choosing which symbols to pull in with get_context_for_symbol' and gives a clear contrast with alternatives (it is cheap because it has no bodies or effect graph, and it avoids failed lookups). This tells the agent exactly when to use it, when not to, and which alternative to select.

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