mcp_server 0.10.0

• Each toolset supplies its own instructions, and a deployment appends to them rather than
  replacing them. The initialize instructions are now each toolset's own text
  (McpToolset>>instructions), joined in registration order. The server-wide text is split three
  ways: McpSessionToolset has the transaction text, McpMutationToolset the compile-conflict line,
  and McpExecutionToolset the searching advice. The paragraph listing the image-changing tools is
  gone, since each tool's description and the [session] line already say their work is
  uncommitted. Because each text names only its own toolset's tools, a narrowed surface is no longer
  told about tools it lacks. McpServer defaultToolsetNames now starts with those three, in that
  order. The toolsets' text is hard-coded; if you want different wording, load a different toolset.
  Breaking: McpRouter>>serverInstructions: is now deploymentInstructions: and appends,
  so neither '' nor any other value can replace or silence the toolsets' text. MCP_INSTRUCTIONS_FILE is now
  MCP_DEPLOYMENT_INSTRUCTIONS_FILE, and the old name is ignored. Other renames:
  maxServerInstructionsSize is now maxDeploymentInstructionsSize, and the bootstrap keyword
  instructions: is now deploymentInstructions:. McpServer class>>defaultServerInstructions is
  gone. A new deployment-instructions.txt.example holds placeholder text: copy it to
  deployment-instructions.txt (git-ignored), edit it, and pass that as
  MCP_DEPLOYMENT_INSTRUCTIONS_FILE; the scripts don't read it unless you name it.

Installing on GemStone 3.7.x without Rowan

Download mcp_server-0.10.0.gs below and this release's source code archive,
unpack the archive, and from its directory run:

./install.sh --from-gs /path/to/mcp_server-0.10.0.gs

The file is the Core and Auth components with their unit tests, tested on
3.7.5 and 3.7.6 before this release was published. On a Rowan image, install from the
source with ./install.sh instead. See the README's Install & run.

mcp_server 0.9.0

• The server is now a Rowan project, Mcp, in Tonel. Breaking: installing needs a stone on a
  Rowan 3 extent (extent0.rowan3.dbf); install.sh refuses one without Rowan. The packages
  (Mcp-Core, Mcp-Tests, Mcp-Auth, Mcp-Auth-Tests, Mcp-Grail, Mcp-Grail-Tests) live under
  src/, the specs and the Core, Auth and optional Grail components under rowan/, and the
  .gs groups and their loaders are gone. Changes are made in the image and written out with the new
  ./write-project.sh. install.sh migrates an image installed from .gs. --grail now loads the
  Grail component, which needs a 4.0 image with both Grail and Rowan — 4.0.0.a5 is the first to
  ship a Rowan extent.

• 3.7.x without Rowan installs a generated topaz file-out. ./export-gs.sh writes Core +
  Auth as one mcp_server.gs with GemStone's own Rowan exporter (no stone needed), and
  ./install.sh --from-gs <file> files it into a stock extent0.dbf. The file is never committed.
  CI now runs four legs on every pull request: 3.7.5 and 3.7.6 from the file-out on a stock extent,
  and 4.0.0.a5 — moved up from a3 — through Rowan on its extent0.rowan3.dbf, with and without
  Grail. Pushing a v<version> tag on main now publishes a GitHub Release with the file-out
  attached, after testing that exact file on 3.7.5 and 3.7.6 (release.yml).

• The scripts no longer read a .topazini. Every topaz login passes -i. Breaking for
  anyone who kept settings for these scripts there: they belong in .setenv. A .topazini in the
  checkout made install.sh report a failed load over one that had succeeded. CI now plants a hostile
  one on every leg and fails if any topaz reads it.

• Forked gems reach the stone by localhost
  (#56). The front end, each worker and a Grail
  test gem pinned their own host to localhost but took the stone's from the machine's host name
  whenever the launching login named none — as run-server.sh's does. Where that name did not
  resolve, or resolved to a LAN address, no worker could log in. A host the login names is still
  used. New suite McpWorkerLoginTest.

• find_python_senders takes every position from Grail
  (#58). Calls and references are placed by
  BaseException pythonSendSitesIn:selector:
  (GemTalk/Grail#1137), which answers each send
  from the VM's send table with its Python position, the same way on both codegen paths. The
  readers that parsed ___curPos___ stores and ___GRAILPOS___ trailers out of generated
  Smalltalk are gone, as is the IR path's line counting. A builtin's probe twin is still one hit,
  now keyed by its PEP 657 span.

• compile_method ends the stored source with a newline
  (#64). A client almost never sends one, and
  every other way a method reaches the image stores one, so ./write-project.sh wrote a method
  compiled through the tool without the blank line before its closing ]. Only a missing final
  newline is added; a source that already ends in one is stored as sent.

• The session-lifetime countdown says minutes
  (#47). The time left on a deadline in the
  uncommitted-work warning was phrased like a configured interval, in minutes only for an exact
  multiple of one, so it nearly always read like "1979 seconds left". It now rounds down to whole
  minutes from one minute up ("32 minutes left") and says seconds below that, so it never promises
  more time than is left. The inactivity bound is phrased as before.

• Every JSON parse failure is now a -32700. McpBase class>>parseBody: caught only Error,
  and not everything the kernel parser can signal is one. It now catches the kernel's Exception,
  looked up through Globals because a Grail image binds #Exception to Python's class first.

• A request body ending in whitespace is no longer a parse error on GemStone 4.0.0.a3. a3's
  JsonParser refuses anything after the outer value, trailing newline included, so a body sent
  from a heredoc or a file, or pretty-printed, answered -32700 — every test.sh request among
  them. McpBase class>>parseBody: now strips trailing JSON whitespace (RFC 8259 §2 allows it)
  before the parse. Two unit tests that pinned a2-era kernel behaviour now accept a3's: the kernel
  writer's corrected surrogate pair, and parsed keys that are Unicode7 where
  #StringConfiguration is Unicode16.

• eval_python runs as __main__ (#50).
  Its namespace was empty, so __name__ was a NameError and a class from type() or
  Enum('F', 'A B') had no __module__ (repr read <class 'T'>). The toolset is the launcher,
  as python -c or the REPL is in CPython, so a fresh namespace now holds __name__ = '__main__'.
  The __module__ half needs a Grail that reads __name__ from the caller's globals
  (GemTalk/Grail#1134).

• find_python_senders places each reference in a method compiled direct to IR
  (#48). A references hit there read
  line ? [compiled to IR: no call-site positions], once per method. Each reference now gets its
  own hit with its Python line, from the same kernel send offsets that place calls, so
  (helper, helper) is two hits. A store to a module global (helper = 2, +=, for helper in,
  :=), which the literal frame had reported as a reference, is no longer one. A method where no
  send lands on the name (del helper, with … as helper) is still reported once, unplaced.

• A deployment can replace the server's instructions. The stock initialize instructions
  name the transaction tools, so a router whose toolsetNames leave those tools out told the model
  about tools it did not have. They are now router config: McpRouter>>serverInstructions: (or
  MCP_INSTRUCTIONS_FILE in run-server.sh / run-auth-server.sh). The value replaces the class
  default, '' sends none, and anything over 32,768 characters is refused where it is configured.
  Breaking: the worker bootstrap selector is now
  prepareWorkerWithToolsets:options:serverName:title:version:instructions:frontEnd:cacheName:.

• The stock instructions are shorter, and tell the model how to search a production database.
  The transaction text is tightened throughout. A new paragraph steers the model away from a loop
  over application objects, which can take hours, and toward the application's own collections, their
  indexes and a selection block.

• find_python_senders places each call in a method compiled direct to IR. IR became Grail's
  default in GemTalk/Grail#1087, which turned most
  compiled hits into line ? [compiled to IR: no call-site positions], one per name a method
  called, so two calls on one line read as one. Each call now gets its own hit with its Python line
  and text, the same answer the text path gives. The line comes from the kernel's send offsets,
  rebased to a module line by BaseException pythonPositionsForMethod:, which also supplies its
  text; that rebase is what keeps it working since
  GemTalk/Grail#1164 stopped padding an IR method's
  source.

• find_python_senders finds first-class references in methods compiled direct to IR. The
  references shape matched markers in generated Smalltalk, which an IR method does not have, so
  g = self.helper there answered nothing without saying it could not look. It now reads the
  method's literal frame, where each referenced name survives as a Symbol and attribute stores,
  keyword names and strings stay Strings. Each such method is reported once, as
  line ? [compiled to IR: no call-site positions].

• A find_python_senders reference hit names the method it is in. Its (Class>>… env 1)
  suffix printed the generated-code marker the hit was found by (___pyAttrLoad___:), which names
  no method, so get_method_source could not open it. It now prints the containing method's
  selector, as a compiled hit always has.

• find_python_senders says when a method was compiled direct to IR, and stops losing its
  recursive calls. Under GRAIL_IR_CODEGEN a method carries no position store, and the
  search now asks Grail which kind of method it is instead of reading the Python as generated
  Smalltalk; its calls are now placed (see above). A recursive call in one was previously dropped
  as arity glue. A bare line ? now means only that a text-compiled source could not be read or
  placed.

• find_python_senders searches nested and function-local classes. Its compiled-shape scope
  now comes from importlib pythonClasses
  (GemTalk/Grail#885) instead of the
  GrailCanonicalClasses registry, which records module-scope class statements only. A call from
  Outer.Inner or from a class defined inside a function used to be answered no senders. It is
  now found and labelled as Python prints it (mod.Outer.Inner.probe). The Smalltalk-defined bases
  Grail answers with it are searched too, labelled builtins.int and so on. The class count in the
  trailer is now a total rather than a floor, and the trailer names the one new gap Grail reports:
  after a Grail install resets the registry, a committed module's classes are missing until it is
  imported again. No tool, option or schema changed.

• The Python browsing and search tools decode selectors through Grail.
  McpGrailToolset>>pythonNameOfSelector: now delegates to importlib pythonNameOfSelector:
  (GemTalk/Grail#884) instead of reimplementing the
  manglin...