bantamkit 0.27.0__tar.gz

bantamkit-0.27.0/.gitignore

@@ -0,0 +1,11 @@
+.venv/
+__pycache__/
+*.egg-info/
+dist/
+.DS_Store
+.pytest_cache/
+.ruff_cache/
+.superpowers/
+.bantam-memory/
+.bantamkit/memory/
+.shiftwork/

bantamkit-0.27.0/PKG-INFO

@@ -0,0 +1,207 @@
+Metadata-Version: 2.5
+Name: bantamkit
+Version: 0.27.0
+Summary: bantamweight tooling — harness primitives that lift small-model agents
+License-Expression: MIT
+Requires-Python: >=3.11
+Requires-Dist: httpx>=0.27
+Requires-Dist: jsonschema>=4.21
+Requires-Dist: pyyaml>=6.0
+Provides-Extra: dev
+Requires-Dist: hatchling>=1.24; extra == 'dev'
+Requires-Dist: pytest>=8.0; extra == 'dev'
+Requires-Dist: ruff>=0.4; extra == 'dev'
+Provides-Extra: mcp
+Requires-Dist: mcp<3,>=2.0; extra == 'mcp'
+Description-Content-Type: text/markdown
+
+# bantamkit
+
+Harness primitives that lift small-model agents: a per-person memory store, JSON
+validation, shift-work accounting, a document reader, and a skill-catalogue
+auditor — served to any MCP host over stdio.
+
+This is the **Python** distribution. There is a second, independent
+implementation of the same surface on npm as
+[`bantamkit-mcp`](https://www.npmjs.com/package/bantamkit-mcp), written in pure
+Node. The two share a memory store on disk and are held to the same answers by a
+conformance suite, so you can install whichever one your host makes easy. What
+the two do *not* agree on is written down in
+[`docs/porting.md`](https://github.com/Ink01101011/bantamkit/blob/main/docs/porting.md)
+and summarised at the bottom of this page.
+
+## Install and run
+
+```bash
+pipx run --spec "bantamkit[mcp]" bantamkit-mcp --assets-root
+```
+
+or into an environment you keep:
+
+```bash
+pip install "bantamkit[mcp]"
+bantamkit-mcp --help
+```
+
+The `[mcp]` extra pulls the MCP SDK. Without it you still get the library and the
+operator CLI, but not the server.
+
+The uv equivalent is `uvx --from "bantamkit[mcp]" bantamkit-mcp`. uv is not
+installed on the machine this README was measured on, so unlike every other
+command here that one is the documented form rather than a measured one.
+
+### Connect it to a host
+
+Every host below runs the same command; only the file and the key around it change. If
+you installed with `pip` into an environment you keep, replace the `command`/`args` pair
+with the absolute path to the `bantamkit-mcp` console script in that environment.
+
+**Claude Code** — one command, no file to edit. `-s user` makes it available in every
+project; drop it for this project only.
+
+```bash
+claude mcp add bantamkit -s user -- pipx run --spec "bantamkit[mcp]" bantamkit-mcp
+```
+
+**Claude Desktop** — `~/Library/Application Support/Claude/claude_desktop_config.json`
+on macOS, `%APPDATA%\Claude\claude_desktop_config.json` on Windows. Top-level key
+`mcpServers`; each entry takes `command`, `args` and an optional `env`.
+
+```json
+{"mcpServers": {"bantamkit": {"command": "pipx", "args": ["run", "--spec", "bantamkit[mcp]", "bantamkit-mcp"]}}}
+```
+
+**GitHub Copilot in VS Code** — `.vscode/mcp.json` for one workspace, or the user
+profile via the **MCP: Open User Configuration** command. Note the top-level key is
+`servers`, not `mcpServers`.
+
+```json
+{"servers": {"bantamkit": {"type": "stdio", "command": "pipx", "args": ["run", "--spec", "bantamkit[mcp]", "bantamkit-mcp"]}}}
+```
+
+**Cursor** — `.cursor/mcp.json` in the project, or `~/.cursor/mcp.json` globally. Back
+to `mcpServers`.
+
+```json
+{"mcpServers": {"bantamkit": {"command": "pipx", "args": ["run", "--spec", "bantamkit[mcp]", "bantamkit-mcp"]}}}
+```
+
+**Anything else that speaks MCP over stdio** runs the console script and talks JSON-RPC
+on its stdin and stdout. Nothing about this package is host-specific.
+
+The Claude Code and Claude Desktop forms were taken from this machine — `claude mcp add
+--help` and an existing config file. The VS Code and Cursor forms are from those
+projects' own documentation, not from a host installed here.
+
+Point `--start` at a directory to choose where project-store discovery begins, or
+`--store` at a single path to disable layering entirely. Do not reach for
+`--store` by reflex: the default is layered, and the layering is most of the
+value.
+
+## What it serves
+
+Eleven tools, measured off a wheel installed into an empty virtualenv:
+
+| tool | what it does |
+|---|---|
+| `memory_save` | store one durable fact, deduped and budgeted |
+| `memory_recall` | retrieve facts matching a query |
+| `memory_compact` | archive the stalest facts to fit the index budget |
+| `validate_json` | validate a document against a JSON Schema |
+| `bantamkit_read` | read a document — text, office formats, pdf |
+| `skill_audit` | audit a skill catalogue for findings |
+| `shiftwork_clock_in` | open a unit of work and get its brief |
+| `shiftwork_clock_out` | close a unit with status and accounting |
+| `shiftwork_status` | report the open cursor |
+| `bantamkit_status` | report store health against its budget |
+| `build_identity` | report the fingerprint of the source on disk |
+
+`build_identity` describes the tree on disk, not the code currently executing —
+useful precisely when a machine carries two installs under one name.
+
+## Requirements
+
+Python 3.11 or newer. Three runtime dependencies — `httpx`, `jsonschema`,
+`pyyaml` — plus `mcp` under the `[mcp]` extra.
+
+## The asset pack
+
+Contracts, schemas, eval tasks, rubrics and tool manifests ship inside the
+package and are located at import time:
+
+```bash
+bantamkit-mcp --assets-root
+```
+
+It prints the resolved directory and its file count. A build that cannot find the
+pack fails rather than producing an artifact without it — that refusal is
+deliberate, because the silent version of it shipped once.
+
+`BANTAMKIT_ASSETS` overrides the location.
+
+## The operator CLI
+
+Memory-store maintenance is a separate surface from the agent-facing tools, and
+it is not served over MCP:
+
+```bash
+python -m bantamkit.memory status     # index size, budget, headroom, archives
+python -m bantamkit.memory lint       # exit 1 if malformed or over budget
+python -m bantamkit.memory compact    # archive the stalest facts
+python -m bantamkit.memory archive <name>
+python -m bantamkit.memory restore <name>
+```
+
+`archive` moves a fact out of the store without deleting it; `restore` brings it
+back by name.
+
+## Sharing a store with the Node server
+
+Both distributions read and write the same on-disk format, so one store can be
+served by either. That is also why a surface present in one and absent from the
+other is not merely a coverage gap — it is a way for two servers to disagree
+about one person's data. Every feature lands in both implementations in the same
+change, and a conformance case compares the two answers before it counts as
+ported.
+
+## Where the two implementations differ, on purpose
+
+- **This side reads pdf, `.doc` and `.rtf`; the Node side refuses them by name.**
+  PDF is read by a stdlib reader written for this project; real OLE2 `.doc` and
+  `.rtf` go through `/usr/bin/textutil`, a macOS built-in that is probed at every
+  call and refused by name where it is absent.
+- **The operator CLI is spelled differently**, and it shows in help text and
+  error messages: `python -m bantamkit.memory` here against `bantamkit-memory`
+  there. There is no third spelling — a pure-npm install has no Python in it, and
+  CPython does not install that console script.
+- **`build_id` hashes the executing tree**, and the two runtimes are two trees, so
+  it differs by construction. `assets_digest` is identical, and that is the one
+  that carries meaning.
+
+Each of these is recorded in the divergence table with a conformance case pinning
+the wording, so the difference cannot drift unnoticed.
+
+## Development
+
+```bash
+git clone https://github.com/Ink01101011/bantamkit
+cd bantamkit
+python -m venv .venv && .venv/bin/pip install -e "runtime-py[dev,mcp]"
+.venv/bin/python -m pytest runtime-py/tests -q
+.venv/bin/ruff check runtime-py
+```
+
+The cross-runtime gate needs Node:
+
+```bash
+node tools/conformance/run.mjs --all
+```
+
+## Links
+
+- Source: https://github.com/Ink01101011/bantamkit
+- The Node distribution: https://www.npmjs.com/package/bantamkit-mcp
+- Install notes: [`docs/install.md`](https://github.com/Ink01101011/bantamkit/blob/main/docs/install.md)
+- What the two runtimes disagree about: [`docs/porting.md`](https://github.com/Ink01101011/bantamkit/blob/main/docs/porting.md)
+
+MIT.

bantamkit-0.27.0/README.md

@@ -0,0 +1,190 @@
+# bantamkit
+
+Harness primitives that lift small-model agents: a per-person memory store, JSON
+validation, shift-work accounting, a document reader, and a skill-catalogue
+auditor — served to any MCP host over stdio.
+
+This is the **Python** distribution. There is a second, independent
+implementation of the same surface on npm as
+[`bantamkit-mcp`](https://www.npmjs.com/package/bantamkit-mcp), written in pure
+Node. The two share a memory store on disk and are held to the same answers by a
+conformance suite, so you can install whichever one your host makes easy. What
+the two do *not* agree on is written down in
+[`docs/porting.md`](https://github.com/Ink01101011/bantamkit/blob/main/docs/porting.md)
+and summarised at the bottom of this page.
+
+## Install and run
+
+```bash
+pipx run --spec "bantamkit[mcp]" bantamkit-mcp --assets-root
+```
+
+or into an environment you keep:
+
+```bash
+pip install "bantamkit[mcp]"
+bantamkit-mcp --help
+```
+
+The `[mcp]` extra pulls the MCP SDK. Without it you still get the library and the
+operator CLI, but not the server.
+
+The uv equivalent is `uvx --from "bantamkit[mcp]" bantamkit-mcp`. uv is not
+installed on the machine this README was measured on, so unlike every other
+command here that one is the documented form rather than a measured one.
+
+### Connect it to a host
+
+Every host below runs the same command; only the file and the key around it change. If
+you installed with `pip` into an environment you keep, replace the `command`/`args` pair
+with the absolute path to the `bantamkit-mcp` console script in that environment.
+
+**Claude Code** — one command, no file to edit. `-s user` makes it available in every
+project; drop it for this project only.
+
+```bash
+claude mcp add bantamkit -s user -- pipx run --spec "bantamkit[mcp]" bantamkit-mcp
+```
+
+**Claude Desktop** — `~/Library/Application Support/Claude/claude_desktop_config.json`
+on macOS, `%APPDATA%\Claude\claude_desktop_config.json` on Windows. Top-level key
+`mcpServers`; each entry takes `command`, `args` and an optional `env`.
+
+```json
+{"mcpServers": {"bantamkit": {"command": "pipx", "args": ["run", "--spec", "bantamkit[mcp]", "bantamkit-mcp"]}}}
+```
+
+**GitHub Copilot in VS Code** — `.vscode/mcp.json` for one workspace, or the user
+profile via the **MCP: Open User Configuration** command. Note the top-level key is
+`servers`, not `mcpServers`.
+
+```json
+{"servers": {"bantamkit": {"type": "stdio", "command": "pipx", "args": ["run", "--spec", "bantamkit[mcp]", "bantamkit-mcp"]}}}
+```
+
+**Cursor** — `.cursor/mcp.json` in the project, or `~/.cursor/mcp.json` globally. Back
+to `mcpServers`.
+
+```json
+{"mcpServers": {"bantamkit": {"command": "pipx", "args": ["run", "--spec", "bantamkit[mcp]", "bantamkit-mcp"]}}}
+```
+
+**Anything else that speaks MCP over stdio** runs the console script and talks JSON-RPC
+on its stdin and stdout. Nothing about this package is host-specific.
+
+The Claude Code and Claude Desktop forms were taken from this machine — `claude mcp add
+--help` and an existing config file. The VS Code and Cursor forms are from those
+projects' own documentation, not from a host installed here.
+
+Point `--start` at a directory to choose where project-store discovery begins, or
+`--store` at a single path to disable layering entirely. Do not reach for
+`--store` by reflex: the default is layered, and the layering is most of the
+value.
+
+## What it serves
+
+Eleven tools, measured off a wheel installed into an empty virtualenv:
+
+| tool | what it does |
+|---|---|
+| `memory_save` | store one durable fact, deduped and budgeted |
+| `memory_recall` | retrieve facts matching a query |
+| `memory_compact` | archive the stalest facts to fit the index budget |
+| `validate_json` | validate a document against a JSON Schema |
+| `bantamkit_read` | read a document — text, office formats, pdf |
+| `skill_audit` | audit a skill catalogue for findings |
+| `shiftwork_clock_in` | open a unit of work and get its brief |
+| `shiftwork_clock_out` | close a unit with status and accounting |
+| `shiftwork_status` | report the open cursor |
+| `bantamkit_status` | report store health against its budget |
+| `build_identity` | report the fingerprint of the source on disk |
+
+`build_identity` describes the tree on disk, not the code currently executing —
+useful precisely when a machine carries two installs under one name.
+
+## Requirements
+
+Python 3.11 or newer. Three runtime dependencies — `httpx`, `jsonschema`,
+`pyyaml` — plus `mcp` under the `[mcp]` extra.
+
+## The asset pack
+
+Contracts, schemas, eval tasks, rubrics and tool manifests ship inside the
+package and are located at import time:
+
+```bash
+bantamkit-mcp --assets-root
+```
+
+It prints the resolved directory and its file count. A build that cannot find the
+pack fails rather than producing an artifact without it — that refusal is
+deliberate, because the silent version of it shipped once.
+
+`BANTAMKIT_ASSETS` overrides the location.
+
+## The operator CLI
+
+Memory-store maintenance is a separate surface from the agent-facing tools, and
+it is not served over MCP:
+
+```bash
+python -m bantamkit.memory status     # index size, budget, headroom, archives
+python -m bantamkit.memory lint       # exit 1 if malformed or over budget
+python -m bantamkit.memory compact    # archive the stalest facts
+python -m bantamkit.memory archive <name>
+python -m bantamkit.memory restore <name>
+```
+
+`archive` moves a fact out of the store without deleting it; `restore` brings it
+back by name.
+
+## Sharing a store with the Node server
+
+Both distributions read and write the same on-disk format, so one store can be
+served by either. That is also why a surface present in one and absent from the
+other is not merely a coverage gap — it is a way for two servers to disagree
+about one person's data. Every feature lands in both implementations in the same
+change, and a conformance case compares the two answers before it counts as
+ported.
+
+## Where the two implementations differ, on purpose
+
+- **This side reads pdf, `.doc` and `.rtf`; the Node side refuses them by name.**
+  PDF is read by a stdlib reader written for this project; real OLE2 `.doc` and
+  `.rtf` go through `/usr/bin/textutil`, a macOS built-in that is probed at every
+  call and refused by name where it is absent.
+- **The operator CLI is spelled differently**, and it shows in help text and
+  error messages: `python -m bantamkit.memory` here against `bantamkit-memory`
+  there. There is no third spelling — a pure-npm install has no Python in it, and
+  CPython does not install that console script.
+- **`build_id` hashes the executing tree**, and the two runtimes are two trees, so
+  it differs by construction. `assets_digest` is identical, and that is the one
+  that carries meaning.
+
+Each of these is recorded in the divergence table with a conformance case pinning
+the wording, so the difference cannot drift unnoticed.
+
+## Development
+
+```bash
+git clone https://github.com/Ink01101011/bantamkit
+cd bantamkit
+python -m venv .venv && .venv/bin/pip install -e "runtime-py[dev,mcp]"
+.venv/bin/python -m pytest runtime-py/tests -q
+.venv/bin/ruff check runtime-py
+```
+
+The cross-runtime gate needs Node:
+
+```bash
+node tools/conformance/run.mjs --all
+```
+
+## Links
+
+- Source: https://github.com/Ink01101011/bantamkit
+- The Node distribution: https://www.npmjs.com/package/bantamkit-mcp
+- Install notes: [`docs/install.md`](https://github.com/Ink01101011/bantamkit/blob/main/docs/install.md)
+- What the two runtimes disagree about: [`docs/porting.md`](https://github.com/Ink01101011/bantamkit/blob/main/docs/porting.md)
+
+MIT.

bantamkit-0.27.0/_assets/contracts/default.yaml

@@ -0,0 +1,90 @@
+name: default
+schema_instruction: "Return ONLY a JSON object matching this JSON Schema. No prose.\n"
+schema_retry: "{error}\nReturn ONLY a JSON object matching the schema."
+critique_feedback: "A reviewer scored your answer {score}/10 (needs >= {threshold}). Feedback: {feedback}\nIf the feedback says a value is missing, unverified, or absent from your evidence, that is a fact you never looked up: call your tools and read the source that has it. Do not reword, generalise, or hedge the previous answer to work around the gap. Then answer again."
+parse_error: "output was not parseable JSON: {detail}"
+validation_error: "JSON does not match schema at '{where}': {detail}"
+json_answer_retry: "Your answer contains no JSON. Restate your final answer as ONLY the JSON requested by the task, with no prose around it."
+loop_note: "(you have now received this exact result {count} times; it will not change. Do something different or give your final answer now)"
+loop_warn: "(STOP calling tools. Give your final answer now, in exactly the format the task asked for.)"
+evidence_line: "{name}({arguments}) -> {observation}"
+evidence_no_observation: "(no observation)"
+evidence_empty: "(no tool calls were made)"
+# The document reader pair's observations (`document_list`, `document_read`). Every string a
+# reader hands back to the model lives here and not in the harness, for the reason the layer
+# rule gives: the mechanics measured in `docread.py` transfer across models, this wording is
+# exactly what does not.
+document_manifest_empty: "no documents are attached to this task"
+document_manifest_part: "{document} ({kind}) part {index} \"{part}\": {rows} rows, numbered 0 to {last}"
+document_manifest_header_row: "  row 0 is the header: {row}"
+document_manifest_first_row: "  row 1 is the first data row: {row}"
+document_manifest_last_row: "  row {index} is the last data row: {row}"
+# What the rendering left out, stated in the one place that says what exists. Measured need
+# (J25, the user's real ~/Downloads, 2026-08-20): `step test.xlsx` is 18.62 MB and the manifest
+# said `4 parts, 28 rows` — all 28 of those rows are empty lines and the file's actual content
+# is 56 embedded PNGs. Every line here is a COUNT: an adjective ("some images") tells a model
+# nothing it can decide with, and silence tells it something false.
+document_manifest_package_media: "{document}: the file also holds {count} embedded file(s) ({what}) totalling {bytes} bytes, which no row can carry — this reader renders no image or embedded object"
+document_manifest_omitted_media: "  NOT in those rows: {count} embedded file(s), {bytes} bytes, anchored to this part"
+document_manifest_omitted_blank: "  {count} of those {rows} rows carry no cell value at all and render as an empty line"
+document_manifest_omitted_format: "  column(s) {where}: {count} cell(s) store a NUMBER under the date/time format {what} — this reader renders the stored serial number verbatim and does not convert it to a date; convert it with that format code if you need one"
+# J25-D3, the PDF reader. Two silences a page-addressable reader can produce that a
+# spreadsheet cannot: a page that rendered no row (a scan, or glyphs no font maps), and
+# characters dropped because the file states no mapping for them. An empty page and a page
+# nobody could read are different facts and the model must be able to tell them apart.
+document_manifest_omitted_unread_page: "  this part rendered NO row: {why}. It draws {count} image(s), {bytes} bytes, that no row can carry — no row means this reader recovered no text from the page, which is NOT the same as the page being empty, and there is no OCR here"
+document_manifest_unread_no_operator: "the page ran no text-showing operator at all, so nothing on it was ever text"
+document_manifest_unread_unmapped: "the page ran {show_ops} text-showing operator(s) and every one of the {unmapped} character(s) they showed came through a font that declares no character map, so this reader dropped them rather than guess at them"
+document_manifest_unread_whitespace: "the page ran {show_ops} text-showing operator(s) and this reader mapped every one of the {vouched} character(s) they showed, and every one of those characters is WHITESPACE — the text was recovered and it carries nothing, which is a fact about the page and not a failure of this reader"
+document_manifest_unread_no_character: "the page ran {show_ops} text-showing operator(s) that put no character on the page at all, neither one this reader could map nor one it had to drop"
+document_manifest_omitted_unmapped: "  {count} character(s) shown on this part are NOT in those rows: their codes came from font(s) with no /ToUnicode map ({what}), so the file stores indices into a font's own glyphs and says nowhere which character each glyph draws — this reader drops them rather than guess, because a guess here is indistinguishable from content"
+document_manifest_omitted_other: "  NOT in those rows: {count} {subject} ({what})"
+document_page_header: "{document} \"{part}\" rows {start}-{end} of {rows}; each line below begins with its own row number"
+document_page_next: "more rows follow: call document_read again with offset={next_offset}"
+document_page_end: "that was the last row of \"{part}\""
+document_page_truncated: "row {index} was too long for one page and was cut: {dropped} bytes dropped"
+document_unknown: "error: no document named {name}; this task has: {available}"
+document_offset_past_end: "error: offset {offset} is past the end of \"{part}\", which has {rows} rows numbered 0 to {last}"
+document_error: "error: {detail}"
+# `bantamkit_read` (the MCP reader, job43) reuses every `document_*` sentence above with the
+# path standing in for `{document}`. Two sentences are genuinely its own: its continuation
+# line names ITS tool, and a part it does not have is a fact about the file, not the task.
+bantamkit_read_page_next: "more rows follow: call bantamkit_read again with offset={next_offset}"
+bantamkit_read_unknown_part: "error: no part named \"{part}\" in {path}; it has: {available}"
+# The `paste` arm's system message (`docs/eval-data/2026-08-20-document-read-bar.md` §10.2,
+# PASTE_MAX_BYTES = 8621 under Amendment 1, 2026-08-20). The arm registers NO tools, so these four lines are the whole of
+# what the model is told ABOUT the corpus; the rows themselves are docread's own rendering,
+# unprefixed and unreformatted, so `paste` and `document_read` differ in DELIVERY and not in
+# content. Clause 4 makes stating the paste's own completeness part of the contract, and
+# `paste_truncated` says the missing rows are unreachable rather than leaving the model to
+# hunt for a tool that is not there: a paste that lets a truncated head read as the whole
+# sheet is a different, worse arm than the one the bar pre-registered.
+document_paste_preamble: "The following document content is attached to this task. Fields in a row are separated by tabs, rows are given in order, and row 0 of each part is its header."
+document_paste_part: "{document} ({kind}) part {index} \"{part}\": {rows} rows, numbered 0 to {last}; {shown} of them are shown below."
+document_paste_complete: "  rows 0 to {last_shown} are shown, which is every row of \"{part}\": this copy is COMPLETE."
+document_paste_truncated: "  rows 0 to {last_shown} are shown; rows {first_missing} to {last} of \"{part}\" are NOT shown and no tool is attached that can fetch them. This copy is PARTIAL."
+document_paste_none: "  no rows of \"{part}\" are shown and no tool is attached that can fetch them."
+# What the model is told when a tool CALL cannot be made or fails, rather than when a tool
+# answers with its own error (`document_unknown` and friends above are that). It lives here
+# for the reason the layer rule gives and for one measured reason: before 2026-08-20 the
+# dispatcher formatted this sentence itself and interpolated the raw exception, so a model
+# that sent one extra argument was handed
+# `_document_tools.<locals>.list_documents() got an unexpected keyword argument 'document'`
+# — a Python qualname, model-facing, owned by no asset and pinned by no golden. The
+# argument-shaped failures are intercepted before the handler is called now, so `{detail}`
+# carries a handler's OWN sentence and no longer a signature fragment.
+tool_failed: "error: {tool} failed: {detail}. fix the arguments and retry."
+tool_arguments: "error: {tool} does not take the arguments it was given. it takes: {accepts}. fix the arguments and retry."
+tool_arguments_none: "error: {tool} takes no arguments at all. call it with none and retry."
+# 2026-08-20, `RB-P86`. The sibling of the two above, one layer in. `select_declared_arguments`
+# drops keys the schema does not declare and type-checks nothing, so `llama3.2:3b` — which
+# emits a JSON-Schema FRAGMENT as the value of a declared parameter,
+# `{"document": {"description": "stock", "type": "string"}}` — got its dict straight through to
+# `docs.get(name)` and the model read `unhashable type: 'dict'`, thirteen times over 432 graded
+# runs. That is CPython's sentence about a hash table, not a tool's sentence about its own
+# arguments, and a 3b that receives it stops calling tools and answers that it cannot access
+# the workbook. What it is told now names the argument, the type the tool declares and the type
+# it was sent, so the next turn has something to correct. One frame for one or many, because
+# the count is not the thing the model has to act on.
+tool_argument_types: "error: {tool} was called with the wrong type of argument. {problems}. fix the arguments and retry."
+tool_argument_type: "{argument} must be type {expected}, not type {actual}"