@evref-bl/pharo-mcp 2.0.0 → 2.1.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/package.json
CHANGED
|
@@ -74,9 +74,57 @@ target under `results`, in request order. An entry that failed carries its
|
|
|
74
74
|
A call naming one target answers exactly what it answers when the argument
|
|
75
75
|
holds a single value.
|
|
76
76
|
|
|
77
|
+
## Changing A Class Or A Method
|
|
78
|
+
|
|
79
|
+
`class_update` and `method_update` take the whole change rather than one
|
|
80
|
+
property each. Every property is optional and at least one is required;
|
|
81
|
+
omitted ones are left alone.
|
|
82
|
+
|
|
83
|
+
Scalar properties are replaced by value, and so are the collections that hold
|
|
84
|
+
no state:
|
|
85
|
+
|
|
86
|
+
```text
|
|
87
|
+
class_update name, and any of newName, superclass, package, tag, comment,
|
|
88
|
+
layout, traits, classTraits, sharedVariables, sharedPools
|
|
89
|
+
```
|
|
90
|
+
|
|
91
|
+
Slots are patched instead, through `slots` and `classSlots`, because they hold
|
|
92
|
+
the instance's values. A replacement list cannot tell a rename from a
|
|
93
|
+
remove-plus-add, and the two differ in whether the value survives; it also has
|
|
94
|
+
to be complete, so a stale one silently drops a slot the caller did not know
|
|
95
|
+
about.
|
|
96
|
+
|
|
97
|
+
```text
|
|
98
|
+
slots: { add: [names]
|
|
99
|
+
remove: [names]
|
|
100
|
+
rename: { current: new }
|
|
101
|
+
pullUp: [names] moves them to the superclass
|
|
102
|
+
pushDown: [names] moves them to every direct subclass
|
|
103
|
+
replace: [names] } the whole list; prefer add and remove
|
|
104
|
+
```
|
|
105
|
+
|
|
106
|
+
`method_update` takes `class` and `selector`, then `protocol`, `newSelector`
|
|
107
|
+
or both. A selector change is classified by arity, so the one argument renames,
|
|
108
|
+
adds or removes arguments and updates senders. Name the new argument list in
|
|
109
|
+
`arguments` and the index map is worked out: names that match the current ones
|
|
110
|
+
are kept, new names are added arguments needing `argumentValueExpressions`, and
|
|
111
|
+
current names left out are removed. `permutation` is only for reordering, which
|
|
112
|
+
names cannot express.
|
|
113
|
+
|
|
114
|
+
The changes are applied in dependency order, not the order they were written:
|
|
115
|
+
a superclass change first, because it decides what the rest validates against,
|
|
116
|
+
slots added before anything refers to them and removed last, and a rename last,
|
|
117
|
+
because every other change resolves the target by the name the caller wrote.
|
|
118
|
+
|
|
119
|
+
A change that fails stops the ones after it. This is the opposite of a batch
|
|
120
|
+
over several targets, and deliberately so: these all land on one class or one
|
|
121
|
+
method, so carrying on would leave half a definition nobody asked for. The
|
|
122
|
+
error names the change that failed, the ones already applied, and the ones not
|
|
123
|
+
attempted.
|
|
124
|
+
|
|
77
125
|
## The Advertised Surface
|
|
78
126
|
|
|
79
|
-
Fifteen tools are advertised directly: `tool_search`, `tool_get`, `tool_call`, `class_search`, `class_get`, `class_create`, `class_remove`, `method_search`, `method_source_search`, `method_reference_search`, `method_get`, `method_compile`, `method_remove`, `test_run` and `image_evaluate`. Every other tool is found with `tool_search` and called
|
|
127
|
+
Fifteen tools are advertised directly: `tool_search`, `tool_get`, `tool_call`, `class_search`, `class_get`, `class_create`, `class_remove`, `method_search`, `method_source_search`, `method_reference_search`, `method_get`, `method_compile`, `method_remove`, `test_run` and `image_evaluate`. Every other tool is found with `tool_search` and called by name like any other; `tool_call` does the same for a client that will only send a name its own list holds.
|
|
80
128
|
|
|
81
129
|
A server chooses its own surface before `start`:
|
|
82
130
|
|
|
@@ -90,7 +138,8 @@ The server answers for its own catalogue. `tool_search` ranks it by keyword,
|
|
|
90
138
|
best match first, and answers the closest tools even when none matches every
|
|
91
139
|
word; add words to narrow the ranking. With no query it answers the catalogue's
|
|
92
140
|
size and its groups. `tool_get` returns one tool's metadata and input schema,
|
|
93
|
-
and `tool_call` invokes a tool
|
|
141
|
+
and `tool_call` invokes a tool by nesting its arguments, for a client that cannot
|
|
142
|
+
send a name outside its own list.
|
|
94
143
|
|
|
95
144
|
Search before calling anything less common or high-risk, and read the schema
|
|
96
145
|
before invoking it.
|
|
@@ -88,7 +88,7 @@ Rerun with `force=true` only when the impact is acceptable.
|
|
|
88
88
|
but Pharo found review issues. Inspect the critique rule class, title,
|
|
89
89
|
description, and source interval if present.
|
|
90
90
|
|
|
91
|
-
Use a follow-up `method_compile`, `
|
|
91
|
+
Use a follow-up `method_compile`, `method_update`, `test_run`, or
|
|
92
92
|
`method_get` call depending on the critique.
|
|
93
93
|
|
|
94
94
|
## Repository State Looks Wrong
|
|
@@ -17,8 +17,9 @@ guessing from source or memory.
|
|
|
17
17
|
|
|
18
18
|
- Inspect the tools exposed by the current client; do not rely on remembered
|
|
19
19
|
names or schemas.
|
|
20
|
-
- Use `tool_search`, then `tool_get`, for less common tools.
|
|
21
|
-
|
|
20
|
+
- Use `tool_search`, then `tool_get`, for less common tools. Call one by name
|
|
21
|
+
like any other, or through `tool_call` when the client will only send a name
|
|
22
|
+
its own list holds.
|
|
22
23
|
- Prefer the least-mutating dedicated tool. Use `image_evaluate` only when no
|
|
23
24
|
dedicated tool fits.
|
|
24
25
|
- Start list/search calls with the default page or a small `limit`. Continue
|
|
@@ -123,18 +124,18 @@ MyProjectMCPTool class >> shouldAutoRegister
|
|
|
123
124
|
```
|
|
124
125
|
|
|
125
126
|
Auto-registered external tools are discoverable by default. Agents can find
|
|
126
|
-
them with `tool_search`, inspect them with `tool_get`, and call them
|
|
127
|
-
`tool_call`.
|
|
127
|
+
them with `tool_search`, inspect them with `tool_get`, and call them by name.
|
|
128
128
|
|
|
129
129
|
`MCPToolRegistry` is the server's source of truth for registered tools. In
|
|
130
130
|
normal use, configure it through the `MCP` instance messages below. The
|
|
131
131
|
`tools/list` response contains only the static tool surface cached by the MCP
|
|
132
|
-
instance; discoverable tools remain
|
|
133
|
-
and `
|
|
132
|
+
instance; discoverable tools remain callable, and are found with `tool_search`
|
|
133
|
+
and `tool_get`.
|
|
134
134
|
|
|
135
|
-
Two words govern the surface. A **registered** tool is in the catalog
|
|
136
|
-
|
|
137
|
-
|
|
135
|
+
Two words govern the surface. A **registered** tool is in the catalog, found
|
|
136
|
+
with `tool_search` and `tool_get`, and callable. An **advertised** tool is also
|
|
137
|
+
in `tools/list`. Advertising decides what a client is shown, not what it may
|
|
138
|
+
call.
|
|
138
139
|
|
|
139
140
|
For a server with only your own tools:
|
|
140
141
|
|