1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
// Copyright Two Neutron Stars Incorporated and contributors
// SPDX-License-Identifier: BlueOak-1.0.0
//! `workspace/executeCommand` extension hatch.
//!
//! The implementing crate registers each available command via
//! [`CommandDescriptor`]. Each descriptor becomes its own typed MCP tool
//! (named `execute_<command>`), so agents see documented per-command tools
//! rather than one opaque `execute_command(name, args[])`.
//!
//! If the implementing crate registers no commands, no `execute_*` tool
//! appears in the MCP catalog.
//!
//! Unlike the built-in tools, these are constructed at runtime from
//! implementer-supplied data, so they can't be ZST markers implementing
//! the typed `Tool` trait. They implement `DynTool` directly and the
//! framework registers them via the `register_dyn` hatch.
use ;
/// One implementer-supplied LSP command, surfaced as a single MCP tool.
///
/// The implementing crate owns the contract: name, description, and JSON
/// Schema for the command's arguments. The framework has no way to validate
/// that any given command is safe to expose to agents — that judgement is
/// the implementer's.
/// Register one MCP tool per `CommandDescriptor`. Each is named
/// `execute_<command>` (with `/`, `.`, `-`, and spaces in the LSP command
/// name replaced by `_` for MCP-name friendliness).