# Cluster 4: Meta-Tooling DSLs and Agent-Facing Languages

**Track:** `intent_dsl_survey_20260612`
**Cluster:** 4 — Meta-Tooling DSLs
**Author:** Tier 2 Tech Lead
**Date:** 2026-06-12
**Sources:** 4 entries (2 internal track specs, 2 provider docs)

---

## Entry: mcp_dsl_20260606 (Manual Slop's Internal DSL Placeholder)

### What the Work Is

The `mcp_dsl_20260606` track is a **planned follow-on** to the `mcp_architecture_refactor_20260606` track (which splits the 2,205-line `src/mcp_client.py` into 7 sub-MCP classes). It does not exist yet as implemented code — it is documented as a deferred design exercise in `spec.md` §12.1 and §13.1. The user explicitly expressed interest in an "APL/K/Cosy-inspired" compact dialect for per-MCP tool calling, and the MCP architecture refactor is explicitly designed to *lay the groundwork* without implementing the DSL. Per `spec.md:26`: "A future track MAY introduce a DSL layer; this track stays JSON-compatible and lays no groundwork that would prevent a future DSL."

The design as specced contrasts a JSON call (~80 tokens) with a DSL call (~10 tokens, ~8x reduction):

```python
# JSON (current, per mcp_client.py dispatch interface)
{"name": "py_get_skeleton", "arguments": "{\"path\": \"/src/foo.py\"}"}

# DSL (proposed, per spec.md §12.1)
py k /src/foo.py
```

The DSL is **per-MCP**, not uniform: each sub-MCP (`mcp_file_io`, `mcp_python`, `mcp_c`, `mcp_cpp`, `mcp_web`, `mcp_analysis`) would have its own grammar definition (e.g., `py_grammar.k`, `file_io_grammar.k`). A per-MCP grammar compiler would translate DSL tokens to the JSON dispatch format. Backward compat: the JSON path stays; the DSL is opt-in per MCP.

### What We Take From It

The MCP DSL entry is the **closest project-internal reference** for what an intent-based DSL looks like in this project. It establishes two critical constraints: (1) the DSL is Meta-Tooling-facing, not Application-facing — the Application's `mcp_client.dispatch` interface stays JSON; (2) each sub-MCP is a natural "DSL compilation unit," suggesting the Tier 4 verb vocabulary should be organized per capability cluster rather than as a flat list.

The 8x token-reduction claim (from `spec.md:460`) establishes the **design objective**: the DSL must be compact enough to appear inline in natural language prompts without burning context budget. This is the primary metric.

### Analysis

The DSL design space is described in `spec.md:456-465` (§12.1 Follow-up Track) and `spec.md:488` (external reference to "the user's friend on APL/K/Cosy DSLs for tool calling"). The architecture rationale is in `spec.md:22-26`:

> "DSL future: the user noted a future interest in per-MCP compact DSLs (APL/K/Cosy-inspired) for tool calling instead of JSON. **This is explicitly OUT OF SCOPE for this track** (per user: 'no time for that'). A future track MAY introduce a DSL layer; this track stays JSON-compatible and lays no groundwork that would prevent a future DSL."

The sub-MCP Protocol (`spec.md:65-84`) defines `list_tool_schemas()` as the self-describing interface — each sub-MCP advertises its own capabilities. This is the bridge between the JSON world (where schemas are the tool advertisement) and the DSL world (where the grammar itself is the advertisement). The `SubMCP` Protocol is shown at `spec.md:65-82`:

```python
class SubMCP(Protocol):
    name: str
    description: str
    tools: dict[str, Callable[..., str]]
    def invoke(self, tool_name: str, args: dict[str, Any]) -> Result[str, Any]: ...
    def list_tool_schemas(self) -> list[dict[str, Any]]:
        """Return the JSON-serializable tool schemas for this sub-MCP's tools.
        Used by MCPController.get_tool_schemas() to aggregate the full list
        for the AI's initial context. Per nagent_review takeaway #5 (the
        self-describing tool pattern), this is the data-driven alternative
        to a hard-coded dispatch chain."""
```

The non-goals at `spec.md:42-49` are equally informative: the DSL does NOT change the agent runtime's tool-calling format, does NOT migrate to TypedDict schemas, and does NOT add new tool categories. This delimits the DSL's scope strictly to the Meta-Tooling bridge side.

The `spec.md:456-465` §12.1 explicitly lists the DSL's design parameters:

> "Examples: JSON: `{"name": "py_get_skeleton", "arguments": "{\"path\": \"/src/foo.py\"}"}` (~80 tokens per call); DSL: `py k /src/foo.py` (~10 tokens per call, ~8x reduction). A per-MCP grammar definition (`py_grammar.k`, `file_io_grammar.k`, etc.) could be authored and compiled to a parser. A per-MCP DSL → JSON converter at the dispatch boundary. Backward compat: the JSON path stays; the DSL is opt-in per MCP."

**Citations:** `conductor/tracks/mcp_architecture_refactor_20260606/spec.md:22-26, 42-49, 65-82, 456-465, 488`

### Take

- The DSL is **Meta-Tooling-only**: the Application's `mcp_client.dispatch` stays JSON. The DSL is a bridge-side translation layer.
- **Per-MCP grammar organization** is the right unit of DSL design — each sub-MCP owns its grammar, compiled to a parser that feeds the dispatch boundary.
- The **8x token reduction target** (80 → 10 tokens) is the concrete design objective. The Tier 4 verb vocabulary should be evaluated against this metric.
- The `SubMCP.list_tool_schemas()` Protocol is the bridge between JSON schemas (used by the Application AI) and DSL grammars (used by the Meta-Tooling). It should be the **schema source of truth** for both representations.
- **Backward compat is non-negotiable**: JSON stays, DSL is additive. Any DSL design that would retire the JSON path is out of scope.

---

## Entry: nagent's Bridge DSL (Meta-Tooling Intent DSL)

### What the Work Is

The Bridge DSL is nagent's pattern for external agent communication: a **self-closing XML-like tag protocol** that external agents emit as plain text, which a parser matches and dispatches to actual tool implementations. Where OpenAI/Anthropic function-calling forces the model to emit structured JSON embedded in a `tool_use` block, nagent's bridge lets the model emit text containing `<nagent-read path="..."/>` tags. The parser matches the tag; `execute_read` runs. The model doesn't need to know the function-call schema — it just emits a tag.

In `nagent_takeaways_20260608.md:216-230`, this is explicitly reframed as a **bridge DSL** for Manual Slop's Meta-Tooling:

```
<ms-tool name="read_file" path="src/foo.py" />
<ms-tool name="py_get_skeleton" path="src/foo.py" symbol="MyClass" />
```

The bridge script (`scripts/mma_exec.py` or a future `cli_tool_bridge.py`) translates these to underlying `mcp_client.py` tool calls. External agents (Gemini CLI, OpenCode) do NOT need to know the JSON function-calling schema for every Manual Slop tool — they just emit DSL tags.

### What We Take From It

nagent's Bridge DSL is the **provenance chain** for the Meta-Tooling DSL idea. It demonstrates that a tag-based protocol is more **debuggable** than JSON function-calling: you can `grep` for `<ms-tool` in logs, you can `cat` a conversation file and see the tool call inline with the text, and the format is readable without a JSON parser. The cost is that training data for tag protocols is near zero — function-calling wins on model capability. The resolution is **domain separation**: use function-calling for the Application AI (where training data and schema rigidity are assets), use the Bridge DSL for the Meta-Tooling (where debuggability and brevity win).

### Analysis

The Bridge DSL framing is at `nagent_takeaways_20260608.md:210-230`. Key passage at line 212-214:

> "nagent's pattern. `<nagent-read path="..."/>` is a self-closing tag. The model emits it; the parser matches; `execute_read` runs. The model doesn't need to know the function-call schema for the LLM SDK — it just needs to emit text containing a tag."

And at line 214:

> "Manual Slop today. `read_file(path)` is a function call. The model has to know the function signature, format the JSON, embed it in the right `tool_use` block. The training data for 'emit a `<nagent-read>` tag' is zero; the training data for 'emit a `read_file` tool call' is high. *Function calling wins on capability and on training*; *tag protocols win on debuggability*."

The actionable recommendation at line 216-222:

> "Actionable idea — both, but in different places. This is the *one* place where the existing reports lean toward 'different mechanism, both right.' Don't replace the Application's function calling. But for the Meta-Tooling, document a *Meta-Tooling DSL* in `conductor/code_styleguides/` for use by external agents when they need to invoke Manual Slop's tools via the bridge script. The DSL would look like:
> ```
> <ms-tool name="read_file" path="src/foo.py" />
> <ms-tool name="py_get_skeleton" path="src/foo.py" symbol="MyClass" />
> ```"

The `decisions.md:117-139` (Candidate 4: Intent-based DSL for Meta-Tooling tool calls) confirms the "EXPLICIT WANT" signal from the user and lays out the full design space. At `decisions.md:123-128`:

> "Examples (per the user's 'discovery' or 'combinatorics' hint):
> - `<read src/foo.py:MyClass.method>` — intent: read this symbol
> - `<search "execution clutch">` — intent: semantic search the workspace
> - `<edit src/foo.py:42-50:new code>` — intent: surgical line-range edit
> - `<test tests/test_foo.py::test_bar>` — intent: run a specific test
> - `<discover what calls X>` — intent: dependency trace"

This is explicitly differentiated from the MCP DSL entry: nagent's Bridge DSL is a **bridge-side** protocol that lives between external agents and the `mcp_client.py` dispatch layer, whereas the MCP DSL is a **per-MCP compact dialect** that would compile to JSON. The Bridge DSL is a text-format protocol; the MCP DSL is a binary-ish compact token format.

The "why both right" argument at `nagent_takeaways_20260608.md:214` is the most important single claim in this cluster:

> "Function calling wins on capability and on training; tag protocols win on debuggability."

This is the architectural principle that justifies **two protocol stacks**: the JSON function-calling stack for the Application AI (capability + training) and the tag-based Bridge DSL for the Meta-Tooling (debuggability + brevity).

**Citations:** `conductor/tracks/nagent_review_20260608/nagent_takeaways_20260608.md:210-230`, `conductor/tracks/nagent_review_20260608/decisions.md:117-139`

### Take

- The Bridge DSL is a **self-closing tag protocol** (`<ms-tool name="..." ... />`), not a JSON blob. It is readable as plain text and grep-able without a JSON parser.
- The **domain split** is load-bearing: Application AI uses JSON function-calling (training data + capability). Meta-Tooling uses Bridge DSL (debuggability + brevity + no schema burden on the model).
- The bridge script translates DSL tags → `mcp_client.py` tool calls. The translation layer is the **deployment point** for the DSL.
- The DSL tags should carry **intent**, not just parameters: `<read src/foo.py:MyClass.method>` encodes "read this symbol specifically" as an intentional fragment, not just a path parameter.
- **Training data gap**: the model has near-zero training data for emitting tag protocols. The Bridge DSL works for external Meta-Tooling agents (which can be prompted with the DSL spec directly) but would fail if used for the Application AI without significant fine-tuning.

---

## Entry: OpenAI Function-Calling Schema (2026 Baseline)

### What the Work Is

OpenAI's function-calling schema (as documented at `platform.openai.com/docs/guides/function-calling`) is the **current state-of-the-art JSON format** for AI tool invocation in 2026. It is the dominant baseline — the format most LLMs in production today emit when invoking tools. It uses a JSON Schema for tool definitions, an ID-based `tool_call` / `tool_call_id` round-trip for call-response matching, and a 5-step conversational loop (request → tool call → execute → response → final text). This is what the DSL is explicitly moving *away from* on the record-format dimension (per the user's note: "ignore its record formats as they probably will be less xml/json based"), but it is the standard that any DSL comparison must reference.

### What We Take From It

OpenAI function-calling establishes the **upper bound of schema rigor**: JSON Schema `strict` mode, `required` fields, `additionalProperties: false`, `enum` constraints, and pydantic/Zod integration. Any DSL that discards this rigor must compensate with runtime validation or narrower tool surface. OpenAI also introduces the **namespace** grouping (`"type": "namespace"`) for organizing tools by domain — this is directly relevant to the Tier 4 verb clustering.

### Analysis

The OpenAI function-calling documentation (`platform.openai.com/docs/guides/function-calling`) defines the canonical 5-step tool loop:

1. Make a request to the model with tools it could call
2. Receive a tool call from the model
3. Execute code on the application side with input from the tool call
4. Make a second request to the model with the tool output
5. Receive a final response from the model (or more tool calls)

The tool definition schema fields at `platform.openai.com/docs/guides/function-calling#defining-functions`:

| Field | Description |
|-------|-------------|
| `type` | Always `"function"` |
| `name` | Function name (e.g., `get_weather`) |
| `description` | When and how to use the function |
| `parameters` | JSON Schema defining input arguments |
| `strict` | Whether to enforce strict mode |

The canonical function definition example:

```json
{
  "type": "function",
  "name": "get_weather",
  "description": "Retrieves current weather for the given location.",
  "parameters": {
    "type": "object",
    "properties": {
      "location": {
        "type": "string",
        "description": "City and country e.g. Bogotá, Colombia"
      },
      "units": {
        "type": "string",
        "enum": ["celsius", "fahrenheit"],
        "description": "Units the temperature will be returned in."
      }
    },
    "required": ["location", "units"],
    "additionalProperties": false
  },
  "strict": true
}
```

The tool call response format uses `tool_call_id` for matching and JSON-stringified `arguments`:

```json
{
  "role": "assistant",
  "content": [
    {
      "type": "tool_use",
      "id": "toolu_01A09q90qw90lq917835lq9",
      "name": "get_weather",
      "input": { "location": "San Francisco, CA" }
    }
  ]
}
```

OpenAI's `namespace` grouping is significant for DSL design. At `platform.openai.com/docs/guides/function-calling#defining-namespaces`:

```json
{
  "type": "namespace",
  "name": "crm",
  "description": "CRM tools for customer lookup and order management.",
  "tools": [
    {
      "type": "function",
      "name": "get_customer_profile",
      "description": "Fetch a customer profile by customer ID.",
      "parameters": {
        "type": "object",
        "properties": {
          "customer_id": { "type": "string" }
        },
        "required": ["customer_id"],
        "additionalProperties": false
      }
    }
  ]
}
```

OpenAI's best practices (`platform.openai.com/docs/guides/function-calling#best-practices-for-defining-functions`) are the closest thing to an industry standard for tool design:

1. Write clear and detailed function names, parameter descriptions, and instructions
2. Apply software engineering best practices — make functions obvious and intuitive; use enums to make invalid states unrepresentable
3. Offload the burden from the model and use code where possible — don't make the model fill arguments you already know
4. Keep the number of initially available functions small — aim for fewer than 20 functions available at the start of a turn

Point 4 is particularly relevant to the Tier 4 verb design: **fewer, more capable tools reduce selection ambiguity**. The DSL should prefer `<read src/foo.py:Symbol>` (one compound intent) over separate `<read_file path="..."/>` + `<py_get_symbol symbol="..."/>` calls.

OpenAI also explicitly addresses token cost at `platform.openai.com/docs/guides/function-calling#token-usage`:

> "Under the hood, functions are injected into the system message in a syntax the model has been trained on. This means callable function definitions count against the model's context limit and are billed as input tokens."

This is the direct motivation for the 8x reduction target in the MCP DSL entry: every token spent on tool schema is a token not available for reasoning.

**Citation:** `platform.openai.com/docs/guides/function-calling` (official OpenAI API documentation, 2026)

### Take

- OpenAI function-calling establishes the **schema rigor baseline**: JSON Schema with `strict`, `required`, `additionalProperties: false`, and `enum` constraints. Any DSL that drops these must add runtime validation at the dispatch boundary.
- **Token cost is the primary constraint**: tool schemas are injected into the system prompt and billed as input tokens. The 8x reduction target (80 → 10 tokens) is directly motivated by this.
- The **namespace grouping** (`"type": "namespace"`) is the right model for Tier 4 verb clustering — group related verbs by domain (file I/O, Python AST, search, etc.) rather than a flat list.
- OpenAI's best practice of **fewer, more capable tools** is directly applicable: prefer `<read path:symbol>` compound intents over multiple single-parameter calls.
- The **5-step conversational loop** (request → tool call → execute → response → final text) is the protocol skeleton the DSL must fit. The DSL replaces the JSON serialization step; it doesn't change the loop.

---

## Entry: Anthropic Tool-Use Schema (2026 Baseline)

### What the Work Is

Anthropic's tool-use schema (`docs.anthropic.com/en/docs/agents-and-tools/tool-use/define-tools`) is the **second dominant 2026 baseline** — structurally similar to OpenAI's but with key differences in philosophy and API shape. Where OpenAI uses `"type": "function"` with nested `"function"` object, Anthropic uses a flat structure with `name`, `description`, and `input_schema` as top-level fields. Anthropic also introduces `input_examples` as a first-class field for schema-validated examples, and `strict` as a guarantee mechanism (not just a hint). The `tool_choice` parameter (`auto`, `any`, `tool`, `none`) provides fine-grained control over whether Claude calls a tool at all.

### What We Take From It

Anthropic's tool-use schema demonstrates that **schema conformance can be guaranteed** via `strict: true` — this eliminates the class of errors where the model emits a tool call that partially matches the schema but fails validation. For the DSL, this means runtime validation at the dispatch boundary is not optional: the DSL must guarantee that emitted calls conform to the sub-MCP's JSON schema before reaching `invoke()`. Anthropic's `input_examples` field also suggests a pattern for **teaching the DSL** to models: provide concrete examples of well-formed calls alongside the grammar definition.

### Analysis

Anthropic's tool definition schema fields at `docs.anthropic.com/en/docs/agents-and-tools/tool-use/define-tools`:

| Parameter | Description |
|-----------|-------------|
| `name` | Must match regex `^[a-zA-Z0-9_-]{1,64}$` |
| `description` | Detailed plaintext description of what the tool does, when to use, how it behaves |
| `input_schema` | JSON Schema object defining expected parameters |
| `input_examples` | Optional array of example input objects (schema-validated) to help Claude understand usage |

The canonical Anthropic tool definition:

```json
{
  "name": "get_weather",
  "description": "Get the current weather in a given location",
  "input_schema": {
    "type": "object",
    "properties": {
      "location": {
        "type": "string",
        "description": "The city and state, e.g. San Francisco, CA"
      },
      "unit": {
        "type": "string",
        "enum": ["celsius", "fahrenheit"],
        "description": "The unit of temperature, either 'celsius' or 'fahrenheit'"
      }
    },
    "required": ["location"]
  }
}
```

Anthropic's tool call response format:

```json
{
  "role": "assistant",
  "content": [
    {
      "type": "text",
      "text": "I'll help you check the current weather in San Francisco."
    },
    {
      "type": "tool_use",
      "id": "toolu_01A09q90qw90lq917835lq9",
      "name": "get_weather",
      "input": { "location": "San Francisco, CA" }
    }
  ]
}
```

The `input_examples` field at `docs.anthropic.com/en/docs/agents-and-tools/tool-use/define-tools` is a key differentiator:

```json
{
  "name": "get_weather",
  "description": "Get the current weather in a given location",
  "input_schema": { ... },
  "input_examples": [
    {"location": "San Francisco, CA", "unit": "fahrenheit"},
    {"location": "Tokyo, Japan", "unit": "celsius"},
    {"location": "New York, NY"}
  ]
}
```

Anthropic's best practices (`docs.anthropic.com/en/docs/agents-and-tools/tool-use/define-tools#best-practices-for-tool-definitions`) are functionally identical to OpenAI's but with stronger language on description quality:

> "Provide extremely detailed descriptions. This is by far the most important factor in tool performance. Your descriptions should explain every detail about the tool, including: What the tool does, When it should be used (and when it shouldn't), What each parameter means and how it affects the tool's behavior, Any important caveats or limitations."

The `strict` parameter at `docs.anthropic.com/en/docs/agents-and-tools/tool-use/define-tools` is described as a **guarantee**, not a hint:

> "Add `strict: true` to your tool definitions to ensure Claude's tool calls always match your schema exactly."

And at `docs.anthropic.com/en/docs/agents-and-tools/tool-use/define-tools#forcing-tool-use`:

> "Combine `tool_choice: {"type": "any"}` with strict tool use to guarantee both that one of your tools will be called AND that the tool inputs strictly follow your schema."

The `tool_choice` control (`auto`, `any`, `tool`, `none`) is Anthropic's mechanism for forcing tool use. The `none` option prevents tool use entirely. The `tool` option forces a specific tool. The `any` option forces *some* tool to be called.

Anthropic's tool-use system prompt construction at `docs.anthropic.com/en/docs/agents-and-tools/tool-use/define-tools#tool-use-system-prompt` is also instructive:

> "When you call the Claude API with the `tools` parameter, the API constructs a special system prompt from the tool definitions, tool configuration, and any user-specified system prompt. The constructed prompt is designed to instruct the model to use the specified tool(s) and provide the necessary context for the tool to operate properly."

The constructed prompt injects: formatting instructions, tool definitions in JSON Schema format, user system prompt, and tool configuration. This is the same mechanism OpenAI uses — the schema is injected as part of the system prompt, confirming that **token cost is proportional to schema verbosity**.

**Citation:** `docs.anthropic.com/en/docs/agents-and-tools/tool-use/define-tools` (official Anthropic documentation, 2026)

### Take

- Anthropic's `strict: true` guarantees schema conformance. The DSL **must** have a runtime validation layer at the dispatch boundary that rejects non-conformant calls before they reach `invoke()`. Without this, the DSL inherits the class of "partial schema match" bugs that `strict` was designed to eliminate.
- **`input_examples` as first-class schema field** is a model for how to teach the DSL: provide 2-3 schema-validated examples of well-formed calls alongside the grammar definition. This is the DSL equivalent of Anthropic's `input_examples` — concrete instances, not just rules.
- The **`tool_choice` control** (`auto`/`any`/`tool`/`none`) maps to Tier 4 verb design: `fuzzy` corresponds to `auto` (let the model decide), `try`/`recover` corresponds to `any` (must call something), and `assumewide` corresponds to forcing a broad-capability tool.
- Anthropic's **flat tool structure** (no `{"type": "function", "function": {...}}` nesting) is simpler to parse and generates less JSON overhead. A DSL targeting similar brevity should prefer flat attribute lists over nested structures.
- The **tool-use system prompt** is constructed by the provider from the schema — confirming that the DSL's grammar definition feeds the same injection mechanism as JSON Schema. The DSL must be **serializable to the schema format** the provider expects, or the schema must be derived from the grammar.

---

## Synthesis for the DSL

This section maps each Tier 4 verb to the entry that grounds it, providing the justification chain for section 4's Tier 4 verb justifications.

### `fuzzy`

**Grounded by:** Entry 2 (nagent Bridge DSL) + Entry 1 (MCP DSL)

`fuzzy` encodes the "discover what calls X" / "semantic search" intent from `decisions.md:128`. nagent's Bridge DSL is explicitly designed for **discovery and combinatorics** (per the user's hint at `decisions.md:119`). The DSL tag protocol is more suited to fuzzy matching than JSON function-calling because the tag format is self-delimiting and grep-able: `<discover what calls X>` is a single readable token, whereas the equivalent JSON function call requires knowing the exact tool name and parameter schema. The MCP DSL's per-MCP grammar organization supports `fuzzy` at the grammar level: each sub-MCP's grammar can define `fuzzy` as a compound intent that expands to multiple underlying tool calls.

### `try` / `recover`

**Grounded by:** Entry 2 (nagent Bridge DSL) + Entry 3 (OpenAI)

`try` / `recover` encodes nagent's visible retry pattern (`nagent_takeaways_20260608.md:182-206`). The nagent pattern appends a `<system>` correction entry to the conversation on parse failure, so the model sees its own failure and the correction. This is the protocol-level equivalent of `try` / `recover`: attempt the call, and if it fails (parse failure, not-found, error), recover by injecting a correction. OpenAI's 5-step conversational loop (`platform.openai.com/docs/guides/function-calling#the-tool-calling-flow`) provides the structural skeleton: the loop is inherently a try/recover cycle (execute → return result → model decides next step). The Bridge DSL's tag protocol makes this cycle visible and editable in the conversation log — each `try` / `recover` round-trip is a visible `<ms-tool>` / `<system>` tag pair.

### `sandbox`

**Grounded by:** Entry 3 (OpenAI) + Entry 4 (Anthropic)

`sandbox` is not directly present in OpenAI or Anthropic schemas (neither provider has a native sandbox concept), but both providers document **tool execution environments** that imply sandboxing. OpenAI's `computer use` tool (`platform.openai.com/docs/guides/tools-computer-use`) and Anthropic's `code_execution` tool are the canonical examples: the tool runs in an isolated environment, returns output, and the model continues. The DSL's `sandbox` verb should map to the pattern of "execute in isolated environment, return semantic result" — which is the dominant pattern across both providers' tool ecosystems. The `SubMCP` architecture from Entry 1 (`spec.md:65-84`) provides the deployment model: `mcp_analysis.py` (with `derive_code_path`, `get_ui_performance`) is the natural home for sandboxed analysis tools.

### `audit`

**Grounded by:** Entry 1 (MCP DSL) + Entry 2 (nagent Bridge DSL)

`audit` is grounded in nagent's self-describing tool pattern (`nagent_takeaways_20260608.md:234-249`), which is the conceptual model for `SubMCP.list_tool_schemas()` (`spec.md:75-80`). The `list_tool_schemas()` method is the audit mechanism: it is the self-reporting interface that lets the DSL (and any external consumer) discover what tools exist without consulting a hard-coded registry. The Bridge DSL's `--description` pattern from nagent (`nagent_takeaways_20260608.md:236-242`) extends this to the command line: `bin/nagent:exit_on_description(description)` prints the tool description and exits when `--description` is in `argv`. For the DSL, `audit` means: enumerate all available tools with their schemas, descriptions, and parameter constraints. This is `MCPController.get_tool_schemas()` — it is the audit verb materialized as a method.

### `didyoumean`

**Grounded by:** Entry 2 (nagent Bridge DSL) + Entry 4 (Anthropic)

`didyoumean` is grounded in the Bridge DSL's **intent-based design** (`decisions.md:123-128`), where the DSL tags encode intent rather than just parameters. `<read src/foo.py:MyClass.method>` is a `read` call with a `didyoumean`-style refinement built into the symbol resolution. The Anthropic `input_examples` field (`docs.anthropic.com/en/docs/agents-and-tools/tool-use/define-tools#providing-tool-use-examples`) provides the model-side equivalent: providing concrete examples helps the model "guess" the right tool and parameters even when the exact match isn't in the training data. `didyoumean` as a Tier 4 verb means: given an ambiguous intent, propose the closest matching tool(s) and parameters, formatted as DSL suggestions the model can adopt directly.

### `span`

**Grounded by:** Entry 1 (MCP DSL) + Entry 3 (OpenAI)

`span` is grounded in the MCP DSL's per-MCP grammar design (`spec.md:456-465`) and OpenAI's **namespace grouping** (`platform.openai.com/docs/guides/function-calling#defining-namespaces`). A `span` in the DSL context means: given a compound intent, decompose it into the appropriate sub-MCP grammar range. For example, `<read src/foo.py:42-50>` spans the `read_file` tool and the `get_file_slice` tool within `mcp_file_io`. OpenAI's namespace grouping shows how to organize tools by domain: the CRM namespace groups `get_customer_profile` and `list_open_orders`. The DSL's `span` should similarly group related tools and provide domain-level dispatch rather than requiring the model to know each individual tool.

### `offset`

**Grounded by:** Entry 1 (MCP DSL) + Entry 3 (OpenAI)

`offset` is grounded in the MCP DSL's line-range notation (`spec.md:456`: `py k /src/foo.py` with an implied offset for the symbol within the file) and OpenAI's **parameter design principles** (`platform.openai.com/docs/guides/function-calling#best-practices-for-defining-functions`): "Don't make the model fill arguments you already know." `offset` as a Tier 4 verb means: the DSL should support **implicit offset resolution** — given a symbol name, resolve it to a file:line without requiring the model to specify the line number explicitly. This is the difference between `<read src/foo.py:MyClass.method>` (offset resolved by the DSL parser) and `<read_file path="src/foo.py">` (no offset, model must specify line range manually).

### `assumewide`

**Grounded by:** Entry 3 (OpenAI) + Entry 4 (Anthropic)

`assumewide` is grounded in OpenAI's best practice of **fewer, more capable tools** (`platform.openai.com/docs/guides/function-calling#best-practices-for-defining-functions`: "Keep the number of initially available functions small for higher accuracy. Aim for fewer than 20 functions available at the start of a turn.") and Anthropic's `tool_choice: {"type": "tool", "name": "..."}` force-call mechanism (`docs.anthropic.com/en/docs/agents-and-tools/tool-use/define-tools#forcing-tool-use`). `assumewide` means: given a broad or ambiguous intent, select the most capable matching tool (the one with the widest parameter range, the most general description) rather than a narrow specialist. OpenAI's namespace grouping supports this: a `crm.*` namespace call dispatches to the most appropriate CRM tool based on the intent, not a specific named tool. `assumewide` as a verb means: apply the "fewer, more capable" heuristic at call time — prefer tools that can handle a range of inputs over tools that require precise parameter matching.

---

## Summary: Entry-to-Verb Mapping

| Tier 4 Verb | Primary Entry | Secondary Entry | Key Mechanism |
|-------------|---------------|-----------------|---------------|
| `fuzzy` | Entry 2 (nagent Bridge DSL) | Entry 1 (MCP DSL) | Tag protocol for discovery + per-MCP grammar composition |
| `try` / `recover` | Entry 2 (nagent Bridge DSL) | Entry 3 (OpenAI) | Visible retry cycle; 5-step conversational loop |
| `sandbox` | Entry 3 (OpenAI) | Entry 4 (Anthropic) | Isolated execution environments; tool-use system prompt |
| `audit` | Entry 1 (MCP DSL) | Entry 2 (nagent Bridge DSL) | `SubMCP.list_tool_schemas()` self-reporting; `--description` pattern |
| `didyoumean` | Entry 2 (nagent Bridge DSL) | Entry 4 (Anthropic) | Intent-based DSL tags; `input_examples` for disambiguation |
| `span` | Entry 1 (MCP DSL) | Entry 3 (OpenAI) | Per-MCP grammar decomposition; namespace grouping |
| `offset` | Entry 1 (MCP DSL) | Entry 3 (OpenAI) | Symbol resolution in DSL parser; "don't make model fill known args" |
| `assumewide` | Entry 3 (OpenAI) | Entry 4 (Anthropic) | Fewer-capable-tools heuristic; `tool_choice` force-call |

---

*End of Cluster 4 sub-report. Total entries: 4. All claims have citations.*