The MCP server and the terminal should offer dimensional analysis and shader source once #2292 and #2293 land #2298

What you ran: amcli mcp on a build carrying #2292 (MathS.Dimensions) and #2293 (MathS.Shaders), branches feat/dimensional-analysis and feat/shader-source.

What it did: nothing; neither is there. Neither branch adds an entry to Core/Operations/Catalogue.cs (#1684), so the server's CatalogueTest and the terminal's OneShotTest stay green and nothing makes either surface keep up. AGENTS.md asks for both: "an operation the library offers by name is an entry of Core/Operations/Catalogue.cs", and the MCP server "has to expose what the release added".

What it should have done: once both are in a release:

1. Four catalogue entries, as queries:

The names are to agree on; #1019 item 16 asks for the library's own words. The shader entries are text in and text out already. The dimension entries need one addition in the library to be: reading a dimension back from the text Dimension.ToString writes (L M T^-2, L^(1/2), 1, with an ASCII spelling for Θ), so that a caller can pass g: "L T^-2".

On sequence, either each feature's pull request adds its entries with a Tools.NotOffered reason and an OneShot.notOffered name pointing here, which keeps every offered operation in the catalogue at every commit, or the pull request for this issue adds entries and surfaces together. The tests are built for the first, so I would do that.

2. Two MCP tools, each offering two entries, the way am_truth_table offers truth_table and satisfying_assignments:

• am_dimensions: dimensions (name → dimension) and either formula or variables. For a formula: consistent with its dimension, inconsistent naming the subexpression and the two dimensions that disagree, or undetermined naming what is missing (an undeclared variable, a symbolic power of a dimensional base). For variables: the dimensionless groups. As a routing description: call it before trusting a physics formula you derived or transcribed; a term with the wrong units survives algebra that looks right, and sin(x) - sin(x) with x a length is inconsistent even though it simplifies to 0.
• am_shader_source: language (hlsl or glsl), outputs (name → expression) and optionally names (variable → shader expression such as p.x). It answers the code, or declined with the node and the reason the library gives. As a routing description: call it to put a derivative or a closed form into a shader rather than transcribing it, which is where precedence, pow of a negative base and fmod against a floored mod go wrong. It computes what am_evaluate computes, except that since A compiled division by zero over double has no value #2288 a compiled division by zero has no value, while on a GPU it is ±inf.

The README asks for a parameter on an existing tool first, then a prompt, then a tool. A dimensions parameter on am_parse fits the check, but not the groups, which take no formula. And a check that can fail reads better with its own status than inside the parse's warnings. am_to_sympy is the nearest relative of the shader tool, but its name and its answer are stable, and folding languages into it would change both.

Also:

• The check-formula prompt gains a step: where the variables are physical quantities, call am_dimensions with their units before am_domain_check.
• The README gets the two rows of its tools table and one known limit: a dimension's exponents are rational, so L^pi is inconsistent and a symbolic power of a dimensional base is undetermined.
• Every library call goes through Guard.Run, and McpUnitTests drives both tools as a client does.
• Neither needs to be preliminary: each answers what a released API answers.

3. The terminal. The four names go into OneShot.notOffered; one-shot commands can follow if wanted.

Depends on #2292 and #2293, which wait for Accepted. If only one is accepted, the other half of this drops. The milestone is the one that carries them (2.7.0 proposed there).