Hirð

by no-materials

Overview Schema Related Servers Score Discussions

Rust

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinctly different concern: source expression typing, named definitions, effect row explanation, IR rendering, actor protocol, actor graph extraction, and context budgeting. The few tools with overlapping domains (e.g., lookup_definition and get_context_for_symbol) still have clearly different behavior around token budgets and included information.
Naming Consistency5/5
All tools follow a consistent snake_case verb_noun pattern: infer_type, lookup_definition, explain_effect_row, render_ir_fragment, explain_actor_protocol, emit_actor_effect_graph, get_context_for_symbol, get_context_budget. Verbs are descriptive and the pattern is predictable throughout.
Tool Count5/5
With eight tools, the server is well-scoped for a language/IR understanding tool. Each tool addresses a meaningful aspect of codebase exploration—definitions, expressions, effect rows, actors, IR, and context budgeting—without unnecessary duplication or excessive surface area.
Completeness4/5
The toolset covers core program understanding workflows: locating definitions, inferring types, explaining effects, examining actors, visualizing actor graphs, and generating context summaries. The main gap is the absence of a general search/list mechanism to enumerate symbols or files without a priori names, though the existing tools largely support the intended workflow.
Average 3.4/5 across 8 of 8 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 162 commits in the last 12 weeks
- Last stable release on July 30, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
This server has been verified by its author.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden. It communicates coordinate semantics (1-based line/column) and that the tool returns type/effect-row information, but it doesn't explicitly say whether the operation is read-only, what it returns in full, or how failures and edge cases are handled.
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?
Single clear sentence, front-loaded with the main action and the key location constraint. There is no filler or repetition.
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?
For a tool with three simple required parameters, the description is minimally adequate, but with no output schema and significant sibling ambiguity, it should say more about expected output or alternatives. It gives useful location details but leaves the agent infer the rest.
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%, and the schema already documents the 1-based and .hird details for all three parameters. The description only groups them as a location, adding no significant meaning beyond the structured schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('infer') on a specific resource (the expression at a source location in a .hird file) and states the output concept (type and effect row). It does not explicitly distinguish itself from sibling tools such as explain_effect_row or lookup_definition, so it misses full differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives no guidance about when to use this tool instead of the available siblings, and no prerequisites or exclusions are mentioned. The only usage context is implied by the mention of a source location.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It discloses the output shape and 'explain' implies a read-only operation, but it does not mention whether there are additional constraints, failure modes, or formatting behaviors.
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 one tight sentence that front-loads the purpose and then states the expected output. There is no wasted text and it does not repeat schema content.
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?
For a two-parameter read-style tool, the output is described, but the terms 'effect row' and 'canonical row' are used without any definition. Since there is no output schema, a little more context about what an effect row contains would reduce ambiguity for an agent.
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 the schema already documents the file and fn_name parameters. The description adds no extra parameter-level guidance, which is acceptable given full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the target resource, 'a function's effect row', and states that it produces both the canonical row and a human-readable explanation of each effect. It is specific about the artifact and output, but it does not explicitly distinguish itself from sibling explain/render tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when this tool should be used versus alternatives such as explain_actor_protocol or render_ir_fragment. The intended usage is only implied by the word 'explain'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that this is a rendering operation with JSON output, which implies a read-only-ish rendering action, but it does not mention error behavior, output shape details beyond JSON, or side effects. That is adequate but not richly transparent.
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?
A single, well-constructed sentence states exactly what the tool does, with no filler and no repetition of schema. Each phrase earns its place: render, typed IR, one top-level definition, JSON.
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?
The two-input schema and simple scope are well documented, and the description makes the tool easy to invoke. However, because there is no output schema and no annotation context, the description leaves the structural shape of the returned JSON unspecified; describing the IR is not enough to make the output fully predictable.
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%, covering both required parameters. The description does not add additional parameter-level detail beyond the schema, but it reinforces the idea that 'name' refers to a top-level definition in the .hird file. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Render') and a clear resource ('the typed IR of one top-level definition') plus a concrete output format ('as JSON'). It is clear and self-contained, though it does not explicitly name or contrast sibling tools such as lookup_definition or infer_type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool instead of the listed alternatives, nor any exclusions or preferred conditions. The phrase 'one top-level definition' constrains scope, but it does not tell an agent how to choose between this and sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotation_contradiction false, but no annotations are present. The description mentions what content will be described, but does not explicitly state side-effect safety, authorization, or failure modes. It is likely a read-only explanation tool, but the description carries the full burden and does not explicitly confirm it.
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?
It is a single, front-loaded sentence with no redundant words. The colon followed by a concise list of the tool's output is good structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with two fully documented parameters and no output schema, the description still indicates the core return topics. It misses only optional context like error handling or what a descriptor; but those are arguably extraneous for the core usage, so it is largely complete.
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 covers both parameters completely. The description adds the concept of protocol components, but it does not introduce parameter semantics, such as must be a valid .hird file or existing actor name, that are absent from the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb-object pair ('Describe an actor's protocol') and enumerates exactly what the protocol includes. It is easy to distinguish by topic from the sibling tools, but it does not explicitly call out how it relates to the other explanation tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not give any guidance on when to choose this tool over its siblings, nor does it mention no prerequisites or error cases. An agent must simply infer from the title and description that this is for actor protocol explanation, but no sibling distinction is made.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are present, the description carries the full burden. It adequately discloses the behavior and expected outputs (source location, type, doc comment, kind), and the term 'look up' strongly implies a read-only operation. It does not explicitly describe what happens when definition is not found, but that's not essential.
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 a single clear sentence that front-loads the verb and resource, then lists the output fields concisely. Every word contributes meaning; there is no padding or repetition of the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a small two-parameter read-only lookup tool, the description covers the essential action and return detail without an output schema. It could additionally mention how failure cases surface (e.g., unknown definition), and it does not state it is read-only, but overall it's nearly complete.
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 input schema already describes both parameters at 100% coverage, so the schema carries the heavy lifting. The description adds only that the lookup applies to a 'top-level' definition, which slightly clarifies 'name' but not indispensably. No extra examples or constraints are added.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Look up') and a well-specified resource ('top-level definition'), plus the fields returned (source location, type, doc comment, kind). It reasonably distinguishes from sibling tools because infers focus on deeper analysis and 'get_context_for_symbol' implies context rather than definition lookup, but it does not explicitly name siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use / when-not-to-use guidance is given. The description implies it is for definition lookup but never says when to prefer it over 'get_context_for_symbol', so ('infer_type', or 'explain_effect_row' is needed. An agent is left to infer the intended scenario from the name and parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of behavioral disclosure. It does disclose that the output is a summary respecting a token budget and includes specific content families, which is useful. However, it says nothing about side effects, read-only behavior, or failure modes.
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 a single compact sentence. It front-loads the core behavior and packs the itemized contents into a list without redundancy or padding, making it fast for an agent to parse.
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?
With no output schema and no annotations, the description must compensate by indicating what the tool returns and what conditions are relevant. It does describe the returned summary areas and the budget behavior, but it omits side effects, prerequisites, or any relationship to the sibling tools, leaving the calling context only partially complete.
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 input schema has 100% description coverage, so file, name, and budget are already documented. The description adds the idea that the output is fitted to the budget, and implies that the listed content types are the requested context, but it does not provide additional semantics beyond the schema.
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 identifies a specific verb and resource: it produces a budget-aware summary of a symbol, and enumerates the concrete contents (kind, signature, effect row, doc, callers, callees). This distinguishes it well from the sibling tools, which target narrower concerns like lookup_definition or explain_effect_row.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance is provided. The description's only implicit signal is the token-budget-aware framing, but it does not tell the agent that this tool should be preferred over siblings like lookup_definition or explain_effect_row, or under what conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It does reveal meaningful traversal semantics: reachability via Send/Await/Spawn, supervisor edges, and transitive tool effects. It does not, however, state whether the operation is read-only, how the graph is represented or emitted, or whether the traversal can be expensive or unbounded.
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?
A single, dense sentence contains all necessary conceptual content: the operation, the root condition, and the edge types traversed. There is no filler or repetition of schema details.
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 absence of an output schema and annotations, the description should clarify what the emitted graph looks like or at least what format it takes. It gives strong coverage of traversal semantics but leaves the result representation unstated. This is acceptable for simple tools, but this graph traversal tool would benefit from a bit more completeness.
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 100% coverage for both parameters, describing 'file' as a Path to a .hird source file and 'actor_name' as the root actor's name. The description adds the interpretive context that actor_name is the root of the graph traversal, but does not need to compensate for any schema gap, so the 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 states a specific verb ('Emit'), a specific resource ('actor/effect graph'), and a clear boundary ('rooted at an actor'). It spells out exactly what edges are included: reachable actors via Send/Await/Spawn, supervisor relationships, and transitive tool effects. This distinguishes it well from sibling tool names like explain_actor_protocol or explain_effect_row.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: when you need the reachable actor/effect graph from a root actor. However, it does not explicitly say when to prefer this over siblings such as explain_actor_protocol or get_context_for_symbol, nor does it state any exclusion conditions. The guidance is adequate but not fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full transparency burden. It usefully notes that the token cost is approximate, and the operation is clearly inspect-like, but it could explicitly state that the file is not modified and no other side effects occur.
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 one focused sentence with no filler. It front-loads the core behavior and spends no words on irrelevant details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter and no output schema, the description gives an agent enough to understand what it costs. The main miss is that the description does not clarify the output shape, only that it estimates token costs.
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%: the only parameter, 'file', is already documented as a path to a .hird source file. The description adds a little context about the file's contents, but most parameter meaning is already handled by the schema.
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 states a specific verb (approximate token costs) and a specific resource (a file's types, effects, actors, supervisors, tools, and function signatures). This makes the tool's purpose clear and distinguishes it from sibling symbols-lookup and explain tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied: the tool tells an agent how many tokens a context window would cost for the file's relevant definitions. However, there is no explicit guidance about when to choose this tool over get_context_for_symbol or other siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![hird MCP server](https://glama.ai/mcp/servers/no-materials/hird/badges/card.svg)](https://glama.ai/mcp/servers/no-materials/hird)

Score Badge

Copy to your README.md:

[![hird MCP server](https://glama.ai/mcp/servers/no-materials/hird/badges/score.svg)](https://glama.ai/mcp/servers/no-materials/hird)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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