Skip to main content
Glama
Sign In
naja-scope

naja-scope

by keplertech
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

get_intent

Read-onlyIdempotent

Retrieve source-level intent erased by netlist lowering: enum/typedef state names, encodings, and symbolic parameter formulas for explaining flattened gates from SystemVerilog or VHDL declarations.

Instructions

Retrieve source-level intent that netlist lowering erases (warm-only). Use when the answer is in the SystemVerilog or VHDL type/declaration, not the flattened gates: enum/typedef state names + encodings (incl. PACKAGE typedefs whose members live in another file), and symbolic PARAMETER or generic expressions (the formula behind a baked-in width). ref: a hierarchical path ('cva6.csr_regfile_i.priv_lvl_q'), a package member ('riscv::PLEN'), or an instance path for its parameters. want: auto | type | fsm_states | parameters. If the intent layer is not loaded, returns a note and you should fall back to get_source.

Input Schema

NameRequiredDescriptionDefault
refYesHierarchical object/instance path or package member such as pkg::NAME.
wantNoIntent fact to retrieve; auto selects from the reference.auto

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.1.9
    • addedInput schema / properties / ref / description
      Added value: +"Hierarchical object/instance path or package member such as pkg::NAME."
    • addedInput schema / properties / want / description
      Added value: +"Intent fact to retrieve; auto selects from the reference."
    • addedInput schema / properties / want / enum
      Added value: +[
+  "auto",
+  "type",
+  "fsm_states",
+  "parameters"
+]
  2. First observedv0.1.8

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world. The description adds real behavioral context beyond them: the 'warm-only' precondition, the fallback note when the intent layer is absent, and that it handles cross-file PACKAGE typedefs. It does not detail output shape, but the precondition disclosure is the key addition.

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-loaded with the core purpose, then usage, then ref/want semantics, then the fallback caveat. Dense parentheticals cost a little readability, but nearly every clause carries information the agent needs.

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?

With no output schema, the description still explains what is returned (state names/encodings, parameter formulas) and what happens on failure (a note prompting fallback to get_source). That is sufficient for an agent to invoke it and handle the degraded case.

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?

Schema coverage is 100%, but the description still adds meaning: it enumerates valid ref forms (hierarchical path, package member like riscv::PLEN, instance path for parameters) and clarifies that want=auto is chosen from the reference. This goes beyond the schema's generic wording.

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 ('Retrieve source-level intent that netlist lowering erases') and immediately scopes it with concrete examples of the fact types returned (enum/typedef state names + encodings, symbolic parameter/generic expressions). This is clearly distinct from the netlist-level siblings it names as fallbacks.

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 says when to use it ('when the answer is in the SystemVerilog or VHDL type/declaration, not the flattened gates') and names the alternative ('fall back to get_source') plus the precondition (intent layer must be loaded, otherwise a note is returned). This routes the agent correctly without inference.

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