describe_topology_authoring_supportExplains the topology note format used when authoring LTspice schematic topologies, so you can write topology descriptions correctly.
Describe the topology note format.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v0.0.1Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered externally. The description adds nothing on top: it does not say what the returned format specification looks like, how long it is, or whether it documents a required structure for contributions. No contradiction with annotations, but no added value either.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single short sentence, front-loaded and free of filler, which is an appropriate size for a no-argument documentation tool. The brevity borders on under-specification rather than efficient conciseness, which keeps it below a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The schema is empty and there is no output schema, so the description is the only place an agent can learn what this call yields. It never states what the 'topology note format' contains, nor how it relates to validate_topology_contribution or ingest_topology_contribution, leaving the agent unable to reason about when it is the right tool despite the trivial invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a parameterless tool applies. No parameter meaning is missing, though no extra semantics are contributed either.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description has a clear verb ('Describe') and a named resource ('topology note format'), so it is not a tautology. However, 'topology note format' is jargon that is never defined, and the description does nothing to separate this tool from close siblings such as describe_topology_block, validate_topology_contribution, or ingest_topology_contribution. An agent cannot tell from the text alone whether this returns a spec, a template, or a list of conventions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance, no prerequisites, and no mention of alternatives among the many topology siblings. A reader can only infer that it should be consulted before authoring or ingesting a contribution, and that inference is not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.