naja-scope

Server Quality Checklist

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

Latest release: v0.1.8
Disambiguation5/5
Each tool has a clearly distinct purpose: find searches globally, get_drivers and get_loads are mirror fanin/fanout queries, get_hierarchy shows module tree, get_intent extracts source-level intent, get_source provides source lines, get_stats aggregates counts, resolve resolves paths, trace_cone traces logic cones, and load/save/manage tools handle session state. No overlapping functionality.
Naming Consistency3/5
Naming conventions are mixed: most tools use 'verb_noun' with underscores (e.g., get_drivers, load_systemverilog), but 'find' and 'status' lack underscores, and 'query_python' uses a language name. The pattern is not fully consistent, though individual names are still readable.
Tool Count4/5
With 20 tools, the server provides a comprehensive set for hardware design analysis (loading, querying, saving, management). The count is slightly above the typical 3-15 range but justified given the domain's complexity; each tool serves a necessary role.
Completeness4/5
The tool surface covers loading multiple formats (SystemVerilog, Verilog, Liberty, snapshots), querying hierarchy, drivers, loads, intent, source, and stats, plus management (reset, save, load, status). Missing write/modify operations, but that aligns with an analysis-focused scope. The Python escape hatch fills gaps.
Average 3.5/5 across 20 of 20 tools scored. Lowest: 1.8/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 83 commits in the last 12 weeks
- No stable releases found
- 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.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
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 full burden. It mentions 'limit/truncated capping', indicating some behavioral trait, but does not disclose whether the tool is read-only, requires specific permissions, or has side effects. The behavior is only partially addressed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short (two sentences) but at the cost of clarity. It is cryptic and uses unclear phrasing, making it not concise in an informative sense. Every sentence should earn its place, but here the first sentence is confusing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 2 parameters, no output schema, and moderate complexity (netlist terms), the description is severely incomplete. It does not explain return value, expected inputs, or how the tool integrates with siblings. The agent lacks sufficient context to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters. It only mentions 'limit/`truncated` capping' but does not describe the 'path' parameter or provide syntax/format details. The description fails to add meaning beyond the schema for either parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses domain-specific jargon ('equipotential', 'leaf readers') without defining the action clearly. It vaguely states what the tool returns but does not explicitly state the verb or resource. The reference to 'Mirror of get_drivers' provides some context, but the purpose remains unclear for an AI agent.
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 mentions 'Mirror of get_drivers' as a sibling, hinting at similarity, but provides no explicit guidance on when to use this tool versus alternatives. No usage conditions or exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It notes the tool is paginated but does not describe whether it is read-only, what the statistics include, how default top works, or any limitations. This is insufficient for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (two fragments), which is concise but lacks necessary detail. It front-loads key words like 'aggregated instance statistics' but omits crucial information. The structure is acceptable given the brevity, but the content is insufficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (3 parameters with no descriptions, no output schema, no annotations), the description is incomplete. It doesn't explain the output format, default behavior, or how pagination works. The information provided is not enough for an agent to correctly invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters. It only vaguely mentions 'per model under an instance (default top)', which relates to the 'path' parameter but is unclear. No explanation for 'limit' or 'cursor' beyond the word 'paginated'. The description adds almost no value to the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool provides aggregated instance statistics per model, which indicates the resource but lacks an explicit verb like 'retrieve' or 'get'. It mentions pagination and a default 'top' instance, which adds context. However, it does not clearly say what the tool does, making it slightly vague.
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 provided on when to use this tool versus alternatives like get_drivers, get_hierarchy, etc. The description only mentions pagination, but does not distinguish the tool's purpose from siblings or specify prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only states loading and definition purpose. No mention of side effects, state changes, or required conditions. Minimal behavioral transparency.
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?
Single sentence is concise and front-loaded, but could be slightly more informative without losing brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Description lacks details on return values, error conditions, and file format. For a simple tool it is incomplete; agent may need to infer behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The lone parameter 'files' is not described in the description despite 0% schema coverage. No explanation of file paths, format, or expected count.
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 states the tool loads Liberty cell libraries and defines primitives for gate netlists. It is specific to Liberty format, but doesn't explicitly differentiate from sibling 'load_primitives'.
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 on when to use vs alternatives (e.g., load_verilog, load_primitives) or prerequisites. The description implies usage for Liberty libraries but lacks explicit context.
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 present, so the description carries the burden. It discloses that it returns file, range, and text, which is helpful. However, it does not address error behavior (e.g., if path does not exist), performance characteristics, or side effects. The description provides moderate transparency but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (one sentence) and front-loaded with the core purpose. However, it omits crucial information about parameters and usage, making it under-informative. Conciseness is positive, but completeness suffers.
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 tool's moderate complexity (2 params, no output schema), the description explains the output structure and provides an example, which is helpful. But it lacks parameter descriptions and error handling context, leaving gaps for effective agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description does not explain what 'path' or 'context_lines' mean. The parameter semantics are entirely missing; the description only mentions output, not input. With 2 parameters and no explanation, this is a critical gap.
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 states the tool's purpose: retrieving SystemVerilog source lines for an object, with a specific example (FF instance to always_ff block). It is specific about the verb ('get') and resource ('source lines'), and the output fields (file, range, text) inform the agent. However, it does not explicitly differentiate from sibling tools, though the purpose is unique enough.
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 provided on when to use this tool versus alternatives like get_hierarchy or trace_cone. There is no mention of prerequisites, limitations, or context where this tool is preferred. The agent must infer usage from the name and description alone.
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?
With no annotations, the description bears full responsibility for behavioral disclosure. It states that the tool performs a glob search (likely read-only) and is paginated via cursor, which implies idempotency. However, it does not explicitly state that the tool has no destructive side effects, which would be helpful for an agent's decision-making.
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 very concise, consisting of two short sentences. It front-loads the primary action ('Glob search names design-wide'), then adds detail about dot patterns, kind values, and pagination. Every sentence provides value, with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the tool having no output schema, the description does not explain what the search results look like (names, paths, or IDs). It also fails to mention whether the search is case-sensitive, matches partial names, or returns exact matches. For a search tool, these details are important for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameter meanings. It explains 'pattern' as a glob search (including the special meaning of dots for paths) and 'kind' by listing valid values. However, it only mentions pagination via 'cursor' without explaining how to use the 'limit' or 'cursor' parameters, leaving two of four parameters partially documented. This is insufficient for a tool with no schema descriptions.
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 states the tool performs a glob search for names design-wide, specifying that a pattern with a dot matches full paths. It lists the valid kinds (instance, net, port, module, any), making the purpose specific and understandable. However, it does not explicitly differentiate from sibling tools like 'resolve' or 'trace_cone' that might also involve searching.
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 provided on when to use this tool versus alternatives. The description mentions pagination via cursor but does not explain the typical use case or prerequisites. There is no indication of when not to use it, leaving the agent to infer context without explicit direction.
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?
With no annotations, the description carries full burden. It discloses idempotency (no-op if already retained) and re-elaboration behavior. However, it omits details on side effects, permissions, or error handling, which are needed for safe invocation.
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 concise and front-loaded with the primary purpose. It avoids extraneous words, but the brevity sacrifices clarity for some readers. Still, it's efficiently structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description uses domain jargon ('warm intent layer', 'cold snapshot', 'SNL↔slang link') without elaboration. With no output schema and many sibling tools, this fails to fully orient an AI agent on how and when to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It mentions 'flist/files' as captured inputs, hinting at their role, but does not explain 'top'. This partial compensation is insufficient for the 3 parameters.
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 states the tool's purpose: making the warm intent layer available for get_intent. It adds context about no-op behavior and re-elaboration, which helps differentiate from simple load operations. However, it does not explicitly distinguish from all siblings like get_intent.
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 provides some usage context (after a cold snapshot, pass flist/files) but does not explicitly state when to use this over alternatives like load_snapshot or get_intent. It hints at prerequisites but lacks clear when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It indicates the tool returns session status, which is likely read-only, but does not explicitly state safety, idempotency, or any constraints. The description lacks depth on behavioral traits.
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 extremely concise, using a single sentence that front-loads the key information ('Current session:'). Every word earns its place, with no redundancy or unnecessary detail.
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 low complexity (no parameters, no output schema), the description adequately explains the return values. However, it does not differentiate from sibling tools like 'get_intent' or 'get_loads', leaving some context missing for optimal selection.
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?
The tool has zero parameters, and the schema coverage is vacuously 100%. Per rubric, absence of parameters yields a baseline of 4. The description does not add parameter semantics, but that is acceptable given no parameters exist.
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 states that the tool returns the current session's loaded design summary and intent layer status. It uses specific terms like 'intent_loaded' and 'intent_loadable', making the purpose evident. However, it could be more explicitly phrased as a verb action (e.g., 'get status'), but the intent is clear.
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 provides no guidance on when to use this tool versus alternatives like 'get_intent' or 'get_loads'. It does not specify prerequisites, side effects, or comparative advantages, leaving the agent without context for selection.
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 provided, so description is the sole source. It discloses limit behavior (capped at 50, max 200, truncated flag, no cursor) and the types of drivers returned. However, it does not mention read-only nature, permission requirements, or potential side effects.
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 concise with two sentences. The first sentence packs a lot of specificity, but the phrasing is slightly fragmented ('What drives this term/net'). No wasted words; front-loads the main purpose.
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 complexity (2 params, no output schema, 0% schema coverage), the description explains the driver types and limit behavior but lacks detail on the output structure (e.g., list format) and exact meaning of `path`. Some gaps remain.
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 0%, so description must compensate. It explains the `limit` parameter (default 50, max 200) but does not provide details about the `path` parameter beyond implying it is the term or net. Some value added but incomplete for both parameters.
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 states the tool returns drivers for a term/net, specifying leaf drivers (FF/gate instances with pin, model, source ref) and top-level ports. It distinguishes from siblings like `get_loads` (loads). The verb is implied but the resource and scope are specific.
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 for obtaining drivers, but no explicit when-to-use or when-not-to-use vs alternatives like `get_loads` or `get_source`. No exclusions or context for choosing this tool.
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 must cover behavioral traits. It mentions that anonymous lowered objects are addressable by '#<id>' and that 'intent=True' retains a link for 'get_intent'. However, it does not disclose side effects, required permissions, or error behaviors, leaving gaps in transparency.
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 concise, consisting of three sentences that front-load the main action and provide key details. There is no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (5 parameters, no annotations, no output schema), the description lacks completeness. It does not explain return values, error handling, or the purpose of the 'keep_assigns' parameter. The tool feels under-documented for effective use.
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?
With 0% schema coverage, the description partially adds meaning: it explains that 'top' is optional, 'files' and 'flist' can be used together, and 'intent' controls a link. However, it does not explain the 'keep_assigns' parameter, which is critical for understanding the tool's behavior.
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 states the tool elaborates SystemVerilog using files or flist with an optional top module. It uses a specific verb ('Elaborate') and resource, and distinguishes it from siblings like 'load_verilog' (different language) and 'load_snapshot' (loading pre-compiled).
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 provide any guidance on when to use this tool versus alternatives such as 'load_verilog' or 'load_liberty'. It lacks prerequisites, context of use, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only states the action and sources, lacking details on side effects, permissions, error handling, or what happens if both parameters are given.
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 sentence with clear, front-loaded purpose. Every word is informative, no redundancy or irrelevant detail.
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?
Essential functionality is described, but lacking details about what primitives are, preconditions, or return behavior. Without output schema, more context would be beneficial for a complete understanding.
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 0%, but description adds value by specifying valid built-in names for 'name' and the expected interface for 'file' (a Python function). Still does not explain type constraints or mutual exclusivity fully.
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?
Clearly states the tool loads primitives via two methods: built-in by name (enumerating 'xilinx' and 'yosys') or from a Python file. This distinguishes it from sibling load tools for different data types.
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?
Implies two usage modes but provides no guidance on when to choose one over the other, nor any comparison with other load tools (load_liberty, load_verilog, etc.).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It discloses that the tool returns descriptors with source refs, handles failures with suggestions, and accepts a kind filter. While it does not mention read-only status or performance characteristics, it provides sufficient behavioral detail for a query-like tool.
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 concise at two sentences plus a trailing snippet. It is front-loaded with the core action and example. The trailing 'kind: instance|term|net.' could be integrated but overall is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description does not explain the return format of 'descriptors' or 'source refs', which is important since there is no output schema. It also lacks details on the did-you-mean mechanism and how 'limit' affects results. For a tool performing resolution, this leaves gaps.
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 description adds meaning for 'path' (with example) and 'kind' (possible values listed), but does not explain the 'limit' parameter. Since schema coverage is 0%, the description partially compensates but leaves one parameter undocumented.
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 states the tool resolves a hierarchical path to descriptors with source refs, and provides an example ('top.u_uart.tx_o'). It also mentions the output kinds (instance/term/net). However, it does not explicitly differentiate from sibling tools like 'find', leaving some ambiguity about when to use this tool over others.
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 explains the primary use case (resolving a path) and mentions error handling (did-you-mean suggestions), but does not provide guidance on when to use this tool versus alternatives (e.g., 'find' or 'get_hierarchy'). No explicit 'when-not-to-use' or prerequisites are given.
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?
The description reveals that the tool persists data to a directory and is version-sensitive, but does not detail side effects, permissions required, or the exact behavior beyond saving. Without annotations, this is adequate but not rich.
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?
Two concise sentences, each essential: the first states the core action, the second adds an important constraint. No wasted words.
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 tool is simple (1 param, no output schema), but the description lacks parameter details and does not mention return value or error conditions. It does provide the version constraint, which is helpful context for usage with load_snapshot.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'directory' is not described in the schema (0% coverage) and the description provides no additional meaning about its expected format, purpose, or behavior. The agent is left guessing what 'directory' refers to.
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 states the action ('Persist the design + source index') and the purpose ('fast reload'). It distinguishes itself from sibling tool 'load_snapshot' by referencing it and noting version compatibility, making its role unique.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (to save for fast reload) and provides a key constraint (version tie-in with load_snapshot rejecting foreign versions). However, it does not explicitly state when not to use or list alternative tools beyond load_snapshot.
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?
With no annotations, the description carries full burden. It discloses that gate netlists carry no source info (so get_source/get_intent cannot answer) and explains the allow_unknown_designs flag effect. But it does not mention if loading is cumulative, idempotent, or what happens on error.
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?
Two concise sentences front-loading the core purpose. Every sentence adds value: main action, pairing/flag behavior, and a limitation. No wasted words.
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 no output schema and no annotations, the description covers the main use case and a key limitation. However, it lacks details on keep_assigns behavior, cumulative loading, and error handling, leaving moderate gaps for a loading tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description should document parameters. It only explains allow_unknown_designs. The files parameter is implied but not explicitly described; keep_assigns is entirely omitted. This leaves significant gaps for the agent.
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 states it loads 'gate-level/structural Verilog netlists', giving a specific verb and resource. It distinguishes from sibling tools like load_systemverilog by specifying 'structural' and mentioning pairing with load_liberty/load_primitives, which are also siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context: pair with load_liberty or load_primitives, and describes allow_unknown_designs behavior. However, does not explicitly state when not to use (e.g., for behavioral code) or name alternatives beyond the pairing siblings.
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 states the action (clear) but lacks details on irreversibility, side effects, or required permissions.
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 sentence, no unnecessary words, front-loads the key action and resource.
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?
Given no output schema and no parameters, the description is adequate for a simple destructive operation, though it could mention confirmation or side effects.
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?
With zero parameters, the schema provides no information. The description meaningfully explains the tool's effect ('clear all loaded designs and session state'), earning a baseline 4.
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 states the verb 'clear' and the resources 'all loaded designs and session state', making it distinct from sibling tools that load or query data.
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 on when to use this tool versus alternatives, nor any exclusions or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully covers behavior: deterministic but caveat about regex-based guesses. It alerts users to potential inaccuracies, which is 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?
The description is a single sentence that packs essential information without redundancy, achieving high conciseness.
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?
The description covers the key output elements but omits details like return format or error cases. Given the tool's simplicity and lack of output schema, 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 single 'module' parameter is not elaborated beyond the schema (0% coverage), but its usage is intuitive. The description implies it accepts a module name, which is sufficient for a simple string input.
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 explicitly lists the output items (ports, instance counts, sequential count, source ref, clock/reset candidates) and distinguishes it from sibling tools like get_stats or get_hierarchy by specifying a deterministic module summary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description warns that clock/reset candidates are a name-based regex guess and advises verification before reliance, implying limited trustworthiness for structural queries. However, it does not explicitly name alternative tools for deeper analysis.
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 it is 'warm-only' and what it returns (enum/typedef states, parameters). However, the phrasing 'Source-level INTENT a netlist erases in lowering' is confusing and lacks clarity on side effects, permissions, or error behavior. More transparency on conditions and constraints would improve this.
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 reasonably concise given the tool's complexity. It front-loads the core purpose and follows with usage details. Some phrases are dense (e.g., 'Source-level INTENT a netlist erases in lowering') which could be streamlined, but overall no wasted sentences.
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?
No output schema is present, so the description must explain return values. It describes that the tool returns enum/typedef state names and encodings, and symbolic parameter expressions. It also mentions error handling (note when intent layer not loaded). While not exhaustive about structure, it provides sufficient context for an AI agent to understand the tool's output.
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 0%, so the description must compensate. It explains the ref parameter with examples of acceptable formats (hierarchical path, package member, instance path) and lists valid values for want ('auto', 'type', 'fsm_states', 'parameters'). This adds significant meaning beyond the bare 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 states that the tool retrieves source-level intent (type/declaration info) from a netlist, specifying it operates on SystemVerilog types and parameters rather than flattened gates. It provides concrete examples of ref and want, making the purpose unambiguous and distinct from siblings like get_source.
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 tells when to use this tool: when the answer is in SystemVerilog type/declaration, not flattened gates. Also provides fallback guidance: if intent layer not loaded, fall back to get_source. This clearly distinguishes it from alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully bears the burden of behavioral disclosure. It details stopping conditions, return values (node_count, counts_by_kind, counts_by_model, frontier), frontier truncation at max_frontier, and cross_hierarchy grouping, providing comprehensive behavioral insight.
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 dense but each sentence adds value. It front-loads the purpose and logically describes behavior and return fields. Could be slightly more concise, but overall effective.
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?
The description covers tool behavior, parameters, and return values well. It explains the frontier structure and cross_hierarchy grouping. Lacks examples or exact formatting for counts, but for a specialized tool it is sufficiently complete.
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 0%, so the description must compensate. It adds meaning for direction (fanin|fanout) and max_frontier (<=200, caps lists), and implies path is a term/net. While not fully structured, it provides critical context beyond the bare 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 states the tool traces the combinational fanin/fanout cone of a term/net via naja's LogicCone, specifying direction and behavior (crosses hierarchy, stops at flops/ports/blackboxes). It distinguishes from siblings like get_drivers/get_loads by focusing on cones.
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 for tracing combinational cones but does not explicitly state when to use this tool versus alternatives or provide conditions for use. No comparative guidance with sibling tools is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes key behavioral traits: fast reload, no re-elaboration unless intent=True. No annotations provided, so description carries full burden and adds value beyond schema.
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?
Two concise sentences, front-loaded with primary purpose, no redundant information.
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?
Adequately covers tool behavior and parameter effects, but lacks prerequisites (e.g., snapshot must exist) and return value info.
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?
Explains the intent parameter's effect (re-elaborate warm intent layer) beyond schema; directory parameter is self-explanatory from context. Schema coverage is 0%, so description compensates well.
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 'Reload a save_snapshot directory in seconds (no re-elaboration)' with a specific verb and resource, and distinguishes from siblings by highlighting speed and lack of full re-elaboration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Clear context for when to use (reload snapshot) and behavior of intent parameter, but does not explicitly state when not to use or mention alternatives like load_intent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses: lists only non-assign children, assign_count, leaf flag, depth<=5, pagination at root via limit/cursor and deeper via children_truncated. Thorough and accurate.
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?
Five sentences packed with information, well-structured: main purpose first, then details. No wasted words.
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?
No output schema, but description explains output structure (leaf flag, assign_count) and pagination. Covers behavior comprehensively for a hierarchy tool.
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 0%, so description must explain parameters. It mentions path (default top), depth (<=5), limit and cursor for pagination, but doesn't explicitly define each parameter's role. Adds partial meaning beyond 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 states it retrieves a hierarchy tree under an instance, specifying it lists non-assign children, how assign is handled, leaf flag, depth limit, and pagination. It distinguishes from sibling tools like find or get_drivers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for obtaining hierarchical structure without assign enumeration, but doesn't explicitly say when to use this vs alternatives. Context is clear, but no exclusions given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses critical behavioral traits: it is an unsandboxed eval/exec in the server process, read-only by convention but not enforced, and output is capped. No annotations were provided, so the description fully covers the safety and execution model.
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 concise with four sentences, each adding value. It is front-loaded with verb and scope, and no extraneous information is present.
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?
Given the dangerous nature of the tool (unsandboxed eval), the description covers its purpose, usage guidelines, behavioral traits (safety, output cap), and disable mechanism. No output schema is provided, but output behavior is described. The description is complete for an agent to decide when and how to use it.
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?
The single parameter 'code' has no schema description (0% coverage), but the description adds meaning by explaining that the code is Python executed in a specific scope with raw bindings. This provides sufficient context for the agent to understand how to use the parameter.
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 the tool as an 'escape hatch' for running Python against the live design, specifying the verb (run Python), resource (live design), and scope (bindings, session, top). It also distinguishes itself from sibling tools by instructing to prefer typed tools above and use this only for queries they cannot express.
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?
The description explicitly states when to use this tool ('only for queries they cannot express') and when not to ('Prefer the typed tools above'). It also mentions that operators can disable it via an environment variable, providing clear guidance on appropriate usage.
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:

[![naja-scope MCP server](https://glama.ai/mcp/servers/najaeda/naja-scope/badges/card.svg)](https://glama.ai/mcp/servers/najaeda/naja-scope)

Score Badge

Copy to your README.md:

[![naja-scope MCP server](https://glama.ai/mcp/servers/najaeda/naja-scope/badges/score.svg)](https://glama.ai/mcp/servers/najaeda/naja-scope)

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/najaeda/naja-scope'

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