tdmcp demonstrates strong definition quality across 38 tools with consistent verb-noun naming, comprehensive parameter schemas, and clear descriptions. Most tools are READ_ONLY (27), with 11 WRITE/DESTRUCTIVE tools clearly marked. All 38 tools have descriptions (average ~120 chars, within rubric baseline of 194). All tools have typed input schemas with parameter descriptions. However, output schemas are not explicitly documented in the source code, only tool names and input schemas are visible. Tool #37 (project_rag_search) and #38 (invoke_registered_prompt) show particularly strong parameter documentation with array filters and enum constraints. Error handling guidance is implicit but not explicitly stated in source. Security risk annotations (destructiveHint) are present via the Risk field. Composition is strong, tools chain naturally (e.g., search → get details → update). No tool combines multiple responsibilities. Overall, the server exhibits B+ to A− quality on naming and parameter definition, but lack of visible output schema documentation and explicit error recovery guidance prevents an A rating.

• Document output schemas for all 38 tools. For each, specify: what fields are returned, their types, and which fields are guaranteed to be present. Use the same JSON Schema format as input params. Example for get_td_info: { type: 'object', properties: { bridge_version: { type: 'string' }, td_version: { type: 'string' }, reachable: { type: 'boolean' } }, required: ['bridge_version', 'reachable'] }.
• Add error recovery guidance to every tool description. For READ_ONLY tools, note 'Returns error with suggested alternatives if not found (e.g., similar node names).' For WRITE tools, add 'May fail if parent node does not exist; call get_td_nodes(parent_path) first to verify.' For DESTRUCTIVE tools, add 'No undo available after execution; consider dry-run or confirmation workflow before calling.'
• Implement and document a dry-run or confirmation-request pattern for all destructive operations (delete_td_node, the create_* family that modifies state). Either add a 'confirm' parameter that defaults to false (requiring explicit intent), or define a separate preview/validate tool that agents call before execution.
• Expand parameter descriptions with specific constraints and examples. For search_td_code, clarify: 'Search query supports regex patterns (case-sensitive, applied to DAT text and parameter expressions; limited to 1000 lines of context per match).' For create_td_node.parameters, document that it accepts a key→value map but specify valid parameter names for the operator_type (e.g., 'For noise operator, valid params include freq, octaves, seed').