Skip to main content
Glama
no-materials

Hirð

by no-materials
OverviewSchemaRelated ServersScoreDiscussions
Rust
Local

Emit actor effect graph

emit_actor_effect_graph
Read-onlyIdempotent

Trace an actor's transitive effects to reveal every reachable actor, supervisor, and tool it depends on, answering 'what does this actor transitively do or depend on'.

Instructions

Emit the actor/effect graph rooted at one actor: every actor reachable through Send, Await, Spawn, and Schedule effects (matched by message type), every supervisor of an included actor together with its whole child set, and every tool an included actor's effect summary names. Use it for 'what does this actor transitively do or depend on'; effect rows are per-process, so no single signature shows this. Use explain_actor_protocol for one actor's own interface and get_context_budget to gauge the size before requesting it. Returns schema_version (1), module, root, and the included actors, supervisors, and tools, whose nodes share the shape of hird emit-effect-graph --json; declarations the root does not reach are omitted. 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, parse_error, or check_error, the last two carrying coded diagnostics in error.data.diagnostics.

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.
actor_nameYesThe root actor's name, as declared in this file. Actors are not resolved through imports; an unknown name fails with `not_found` and `error.data.available_actors`.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
rootYes
toolsYes
actorsYes
moduleYes
supervisorsYes
schema_versionYes

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed4 schema fields changed
    • changedInput schema / properties / actor_name / description
      Previous value: -"The root actor's name."New value: +"The root actor's name, as declared in this file. Actors are not resolved through imports; an unknown name fails with `not_found` and `error.data.available_actors`."
    • 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 / required
      Previous value: -[
-  "file",
-  "actor_name"
-]New value: +[
+  "actor_name",
+  "file"
+]
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "properties": {
+    "actors": {
+      "items": {
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "module": {
+      "type": "string"
+    },
+    "root": {
+      "type": "string"
+    },
+    "schema_version": {
+      "type": "integer"
+    },
+    "supervisors": {
+      "items": {
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "tools": {
+      "items": {
+        "type": "object"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "actors",
+    "module",
+    "root",
+    "schema_version",
+    "supervisors",
+    "tools"
+  ],
+  "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.6/5.0
Behavior5/5

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

Annotations already provide readOnlyHint=true, idempotentHint=true, destructiveHint=false, and the description goes well beyond them: it discloses in-memory directory compilation with caching until a sibling changes, states it 'writes or executes nothing', and enumerates the stable error.code values plus the diagnostics structure on failures. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long (roughly 150 words) but densely packed — scope, usage rationale, alternatives, return shape, read-only behavior, and error codes all in distinct clauses with no redundancy. Purpose is front-loaded. Slightly long, but every sentence earns its place given the tool's complexity.

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 graph-returning tool with compilation, caching, and multi-mode failures, the description covers scope definition, usage context, sibling routing, return shape (schema_version, module, root, actors/supervisors/tools), and the full error contract. An output schema exists, so return values need not be re-explained, and nothing an agent needs to call this correctly is missing.

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% — both file and actor_name are fully documented in the schema (path resolution, import behavior, not_found error with available_actors). The description adds little parameter-specific meaning beyond the schema, so the baseline of 3 applies. The only mild addition is the note that declarations the root does not reach are omitted, which concerns output rather than parameters.

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?

States a specific verb and resource ('Emit the actor/effect graph rooted at one actor') and precisely enumerates the graph's contents (reachable actors via Send/Await/Spawn/Schedule, supervisors with child sets, named tools). Clearly differentiates itself from siblings by naming explain_actor_protocol and get_context_budget as the alternatives for narrower/sizing queries.

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?

Explicitly states the intended use case ('what does this actor transitively do or depend on'), explains why it is needed ('effect rows are per-process, so no single signature shows this'), and names two concrete alternatives with their selection conditions. This is exactly the when/when-not guidance the dimension calls for.

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/no-materials/hird'

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