Universal Netlist MCP server has well-structured tool definitions with consistent naming (verb_noun pattern: list_, search_, query_, run_, export_), complete input schemas with type declarations, and comprehensive parameter descriptions. All 12 tools are explicitly registered with descriptions and Zod schemas. However, descriptions are terse (10-50 chars, well below the 50-200 char LLM-optimized baseline), lack context on WHEN to use each tool, and omit dependency hints. Output schemas are not documented, LLMs cannot predict what fields to expect from responses. Error handling is minimal; no recovery guidance or actionable error messages visible. Tool composition is sound (single responsibility, clear naming distinctions), but descriptions need expansion to guide LLM selection and multi-step planning.

• Expand all tool descriptions to 50-200 characters. Include WHAT the tool does, WHEN to use it (vs. similar tools), and what it returns. Example: 'List designs in a directory. Call this first to discover available designs and their variants before querying components or nets. Returns design paths, names, and variant names.'
• Document output schemas for all tools. Specify field names, types, and nesting. Example: 'Returns {designs: [{path: string, name: string, design_variants: string[]}], total: number, next_cursor?: string}'
• Add error handling guidance to descriptions. Example: 'If design file not found, returns error with available paths. If regex pattern is invalid, returns error with pattern syntax hints.'
• Add a dry-run parameter to export_cadence_netlist or implement a separate preview_cadence_export tool. Let agents validate the export before overwriting.
• Clarify design_variant: either make it always required (with a default value like '<Default>') or always optional with explicit fallback behavior documented in the description.

Inferred effective spec: <=2025-11-25.

• Relies on Logging (deprecated) - log to stderr or use OpenTelemetry