Skip to main content
Glama
Sign In
naja-scope

naja-scope

by keplertech
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

load_intent

Destructive

Loads the source-intent layer for get_intent after SystemVerilog or VHDL elaboration that did not retain intent, re-elaborating from files or a file-list when needed.

Instructions

Make the warm source-intent layer available for get_intent. Use after a SystemVerilog or VHDL load that did not retain intent; do not call for gate-level Verilog, and prefer intent=True on the initial load. This is a no-op when the link is already live; otherwise it replaces the active universe by re-elaborating from explicit or captured flist/files. Returns intent_loaded; missing inputs produce a structured error.

Input Schema

NameRequiredDescriptionDefault
topNoTop module/entity name; omit to reuse the captured or inferred top.
filesNoRTL source paths; omit to reuse captured load inputs.
flistNoSystemVerilog file-list path (not VHDL); omit to reuse captured load inputs.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.1.23
    • changedInput schema / properties / files / description
      Previous value: -"SystemVerilog source paths; omit to reuse captured load inputs."New value: +"RTL source paths; omit to reuse captured load inputs."
    • changedInput schema / properties / flist / description
      Previous value: -"SystemVerilog file-list path; omit to reuse captured load inputs."New value: +"SystemVerilog file-list path (not VHDL); omit to reuse captured load inputs."
    • changedInput schema / properties / top / description
      Previous value: -"Top module name; omit to reuse the captured or inferred top."New value: +"Top module/entity name; omit to reuse the captured or inferred top."
  2. Changed3 schema fields changedv0.1.9
    • addedInput schema / properties / files / description
      Added value: +"SystemVerilog source paths; omit to reuse captured load inputs."
    • addedInput schema / properties / flist / description
      Added value: +"SystemVerilog file-list path; omit to reuse captured load inputs."
    • addedInput schema / properties / top / description
      Added value: +"Top module name; omit to reuse the captured or inferred top."
  3. First observedv0.1.8

TDQS

A4.3/5.0
Behavior4/5

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

Adds real context beyond the annotations: the operation is a no-op if the link is live, otherwise it replaces the active universe, and missing inputs yield a structured error rather than a crash. One tension worth noting: `idempotentHint: false` sits awkwardly with 'no-op when the link is already live', which describes repeat-call-safe behavior; the description does not explain what makes repeat invocation non-idempotent.

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?

Front-loads the purpose, then conditions, exclusion, preferred alternative, side effects, and return value in four tight sentences with no filler. Minor cost: jargon like 'warm source-intent layer' and 're-elaborating' assumes domain familiarity an agent may not have.

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?

With no output schema, the description compensates by naming the return key `intent_loaded` and describing the structured-error path, plus the destructive side effect of replacing the active universe. It would be stronger if it clarified how the idempotent semantics interact with the live-link no-op or what state is lost on replacement.

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 coverage is 100% and each parameter already documents its omit-to-reuse-captured-inputs default, so the schema carries the semantics. The description only echoes the fallback idea ('explicit or captured `flist`/`files`') without adding format, precedence, or interaction rules between `files` and `flist`, so the baseline 3 applies.

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 effect: makes the source-intent layer available for the sibling tool `get_intent`, replacing the active universe via re-elaboration if not already live. It distinguishes itself from `load_systemverilog`, `load_vhdl`, and `load_verilog` by naming the post-load recovery scenario and explicitly excluding gate-level Verilog.

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?

Gives an explicit trigger ('after a SystemVerilog or VHDL load that did not retain intent'), an explicit exclusion ('do not call for gate-level Verilog'), and a preferred alternative ('prefer `intent=True` on the initial load'). It also states the degenerate case (no-op when the link is already live), so an agent can decide before invoking.

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