ltspice-mcp

list_libraries

Read-onlyIdempotent

List loaded LTspice libraries with optional filtering and pagination. Enable detailed view to reveal .SUBCKT and .MODEL names, and flag encrypted vendor files.

Instructions

List loaded libraries. With detail=true, also shows the .SUBCKT and .MODEL names defined in each library (so foundry .bjt/.mod files with hundreds of .MODEL cards are discoverable without guessing), and names encrypted vendor files whose bodies can't be parsed.

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": "list_libraries"
  }
}

Input Schema

Name	Required	Description
`path`	No	Filter to a specific library path
`limit`	No	Max results to return (server caps at 50; page with offset)
`detail`	No	Include model names from each library
`format`	No	Response format: 'json' for structured data, 'text' for human-readable
`offset`	No	Pagination offset

Output Schema

Name	Required	Description	Default
`libraries`	No
`pagination`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Aug 21, 2026

TDQS

D1.1/5.0

Behavior1/5

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

Description provides no information about optional chaining or behavioral effects beyond what the name implies, which is tautological. No annotations are present to compensate for the lack of adequate transparency. The description adds no safety profile context for mutation is molecular, and there is no deviation from the structured data. No annotation or description reveals behaviors that the agent should know about but doesn't disclose. No requirements for multi-agent context, no rate limits mentioned for a scaled API. The Hazard note applies since no annotation-based awareness of mutations or potential for side effects is present.

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?

Almost no structure is present due to clear hardware and missing context, and the output schema is present, adding zero value. The description is very short but extraordinarily cryptic. Otherwise, the answer is impossible or impossible.

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?

This is a completely inadequate description and transparent insight is missing the required depth. The title is irrelevant, and no schema exists or optional is entirely absent, severely limiting the ability to effectively use the tool. The presence of the output_schema does not make up for the level of output. This is broken at the most basic intent level.

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 description is a garbled schema that obfuscates schema meaning, and the parameters shown (#3) are not understood. The schema does heavy lifting by defining the parameter count, but the description fails to clarify their semantic role. Schema coverage is not 100% covered by the description for the needed names. The parameters listed are actually 0.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description is garbled and includes schema/JSON artifacts. The tool name is 'list_libraries' and the title is 'list_libraries', but the description is pure tautology, restating the tool's purpose without a clear verb-resource structure. It provides no meaningful information about listing libraries.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/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 over siblings like list_components or find_model. The garbled text mentions 'with detail=true', suggesting documentation issues, but no guidance is given.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.