Models send tool arguments with hyphenated keys and nested objects. Plugin CLIs built on argparse expect underscore dests and JSON on argv. Two small commits on April 17 closed that gap. The result is unglamorous reliability plumbing - the kind of fix that turns "tool sometimes doesn't work" into "tool works."

The boundary that was failing silently

SMCP exposes plugin CLIs as MCP tools. The model's tool call arrives as a JSON object; SMCP translates that into an argv line for the plugin's argparse-based CLI. Two failure classes had been slipping through that translation:

1. When a model passed a nested object as a tool argument, SMCP was putting the Python repr of the dict on argv. The plugin's argparse parser could not make sense of it, and the call failed in a way that did not point at the right place.
2. Models were inconsistent about hyphenation. Some sent payload_json, some sent payload-json. The CLI's argparse dest was underscore-style, so the hyphenated form sometimes got mapped, sometimes did not, and the argument quietly went missing on the way to the plugin.

Both were silent: the model thought it had called the tool, the tool thought it had been called, and the operator noticed only when an expected effect did not happen.

Fix one: dict on argv as JSON, not repr

Commit f9b4d60 rewrites how execute_plugin_tool emits dict-typed tool arguments. The rule, after the fix, is small enough to fit in a sentence: skip None values, and for dict values, emit the argument name followed by a compact JSON string instead of a Python repr.

The mechanism is the bit that matters. Compact JSON means json.dumps(value, separators=(',',':')) - no spaces, no newlines, no Python repr decoration. The plugin's argparse parser reads the value as a single token, and the receiving code on the plugin side can json.loads it back into a real dict. Lists already passed element-by-element for argparse's nargs, so they were not affected; only the dict case needed a rewrite.

The shape, conceptually:

# before
--catering-payload {'invoice_id': 'INV-1042', 'amount': 19.50, ...}

# after
--catering-payload {"invoice_id":"INV-1042","amount":19.5,...}

before

--catering-payload {'invoice_id': 'INV-1042', 'amount': 19.50, ...}

after

--catering-payload {"invoice_id":"INV-1042","amount":19.5,...}

# before
--catering-payload {'invoice_id': 'INV-1042', 'amount': 19.50, ...}

# after
--catering-payload {"invoice_id":"INV-1042","amount":19.5,...}

The repr form looked correct to a human and was nonsense to a parser. The JSON form is unambiguous, parseable, and exactly what the plugin expected.

Fix two: coalesce hyphen/underscore aliases before argv

Commit 1457fcf adds a small helper, _coalesce_tool_argument_aliases(arguments), called at the top of execute_plugin_tool. The job of the helper is to merge known hyphen/underscore alias pairs into a single canonical form before the argv is built.

The aliases are explicit, not guessed. The helper knows that payload_json and payload-json are the same argument, that catering_invoice_id and catering-invoice-id are the same argument, that invoice_command and invoice-command are the same argument. When both forms appear in the same call, the underscore form wins - because the CLI's argparse dest is underscore-style, and a single canonical form is the only thing the rest of the pipeline knows how to handle. When only one form appears, it is passed through unchanged.

This is the kind of code that looks like it should be obvious and is, in fact, exactly the kind of code that quietly matters. A small, explicit alias table is the difference between a tool that the model can call three different ways and a tool that the model can call one way and the other two just work.

Before and after, in one call

The concrete failure was a catering invoice tool call. The model sent something like:

# before
--catering-payload {'invoice_id': 'INV-1042', 'amount': 19.50, ...}

# after
--catering-payload {"invoice_id":"INV-1042","amount":19.5,...}

tool: catering.invoice arguments: { "payload-json": { "invoice_id": "INV-1042", ... } }

# before
--catering-payload {'invoice_id': 'INV-1042', 'amount': 19.50, ...}

# after
--catering-payload {"invoice_id":"INV-1042","amount":19.5,...}

Before the fixes, that arrived at the plugin as --catering-payload {'invoice_id': 'INV-1042', ...} - the hyphenated key sometimes mapped, sometimes did not, and the value was unparseable when it did. After the fixes, the same call arrives as --catering-payload {"invoice_id":"INV-1042",...} - the hyphen/underscore form is normalized first, the dict is serialized as JSON, and the plugin parses both halves without complaint.

That is the entire fix. It does not redesign the boundary, and it does not solve every MCP arg problem. It does, however, make the catering invoice tool work.

Scope, honestly

Both changes are targeted. The argv build is about 26 lines changed across the two commits, and the alias table is short enough to read in one screen. This is plumbing, not architecture. It does not change how SMCP exposes tools, how plugins register themselves, or how the model reasons about which tool to call. It changes only the last few lines of the boundary - the ones that decide what shape the argument has when it hits the plugin.

The next class of plugin-reliability work is already in the open: argument-type coercion (string-vs-int at the boundary), better error messages when an alias is genuinely unknown, and the question of whether a model-supplied None should be omitted entirely or passed through as a sentinel. None of those are fixed today. They are the things we will write up when they ship.