Skip to main content
Glama
keplertech

naja-scope

by keplertech
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

load_primitives

Destructive

Register built-in Xilinx or Yosys primitive models in the active session, or load a trusted local Python file defining load(db) for custom primitives.

Instructions

Register primitive models in the active session from either a built-in name (xilinx or yosys) or one local Python file defining load(db). Provide one source; name takes precedence when both are set. A custom file executes unsandboxed Python in the server process, so only use trusted code. Use load_liberty instead for standard-cell .lib files. Returns {"ok": true}.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
fileNoLocal Python file defining load(db); used only when name is omitted.
nameNoBuilt-in primitive set to register; when set, file is ignored.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.1.9
    • addedInput schema / properties / file / description
      Added value: +"Local Python file defining load(db); used only when name is omitted."
    • changedInput schema / properties / name / anyOf
      Previous value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "enum": [
+      "xilinx",
+      "yosys"
+    ],
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
    • addedInput schema / properties / name / description
      Added value: +"Built-in primitive set to register; when set, file is ignored."
  2. First observedv0.1.8

TDQS

A4.6/5.0
Behavior5/5

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

Annotations declare a destructive, non-idempotent, open-world write, and the description adds genuinely non-redundant context: custom files execute unsandboxed Python in the server process and must be trusted. It also discloses precedence behavior and the return value `{"ok": true}`.

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?

Three tight sentences that lead with the action and source choice, then the precedence rule, then the risk note and alternative. Slightly dense with clauses, but essentially no wasted text.

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 two-optional-param tool with no output schema, the description covers source selection, precedence, the execution-security caveat, the alternative sibling for a related file format, and the return shape. Nothing needed to invoke it safely 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 coverage is 100% and both parameters are already documented with the same precedence semantics ('used only when name is omitted', 'when set, file is ignored'). The description largely restates that, so the baseline 3 applies; it adds the trusted-code constraint but no additional parameter syntax.

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 and resource ('Register primitive models in the active session') and enumerates the two mutually exclusive sources (built-in `name` or local Python `file`). It also names the sibling it is not (load_liberty), so an agent can route correctly without opening a schema.

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 either/or rule ('Provide one source; `name` takes precedence when both are set') and an explicit alternative for a plausible adjacent task ('Use load_liberty instead for standard-cell `.lib` files'). Both when-to-use and when-not-to-use are covered.

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