Skip to main content
Glama
Sign In
siliconsmith-mcp

siliconsmith-mcp

by RFingAdam
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

explain

Read-only

Returns plain-English explanations for chip-design topics, section headings, glossary terms, or keywords, with matching summaries, full details, source references, and up to four related suggestions.

Instructions

Explain a topic in plain English from the packaged skills and glossary. topic can be a skill name ('chip-design-loop', 'tt-rules', 'amaranth-style', 'myhdl-style', 'cocotb2-tests': you get the overview and the list of sections), a section heading, a glossary term ('latch', 'slack', 'GDS'), or a few keywords. The best match comes back with up to 4 other suggestions. 'list' or an empty topic returns the catalogue. An unknown topic is not an error; it returns suggestions. The summary is the start of the text; details.text has all of it and details.source says where it came from. Start with explain('chip-design-loop').

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "explain"
  }
}

Input Schema

NameRequiredDescriptionDefault
topicNolist

Output Schema

NameRequiredDescriptionDefault
okYes
detailsNo
summaryYes
artifactsNo
next_hintsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.7/5.0
Behavior5/5

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

Beyond the readOnlyHint/destructiveHint annotations, it discloses non-obvious behavior: fuzzy matching returns the best match plus up to 4 suggestions, unknown topics degrade to suggestions rather than errors, and results are split between summary and details.text/details.source. Those are behaviors an agent could not infer from annotations or schema.

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?

Purpose is front-loaded in the first clause, and every sentence carries information (examples, fallback behavior, response fields). It loses a point for being a single dense run-on with stacked parentheticals that is harder to scan than a short bulleted structure would be.

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 one-parameter lookup tool with an output schema, the description covers input forms, matching behavior, fallback semantics, and which response fields hold the full text and provenance. Nothing an agent needs in order to call it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% for the single 'topic' parameter, so the description carries the full burden — and it does, spelling out the accepted value categories (skill name, section heading, glossary term, keywords, 'list', empty) with concrete examples. This more than compensates for the missing schema documentation.

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 opens with a concrete verb and resource: 'Explain a topic in plain English from the packaged skills and glossary.' It then enumerates the accepted topic forms (skill name, section heading, glossary term, keywords), which makes it unmistakably distinct from the sibling file/project/test tools.

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?

It gives strong contextual guidance: the accepted topic shapes, that 'list' or an empty topic returns the catalogue, that unknown topics are not errors, and an explicit recommended first call ('Start with explain("chip-design-loop")'). It does not state when to prefer a sibling such as read_file over this tool, which is the only real gap.

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