MCPL server ids and toolPrefix are unvalidated; prefixes that sanitise to the same Python name drop tools from code_execution #423

What's wrong

Nothing in src/ checks which characters an MCPL server's id or toolPrefix contains (main e6a03170). The toolPrefix doc (src/mcpl/types.ts:399-413) only says it "must not collide".

When buildInjectedTools (src/code-execution/py-runner.ts:558-579) builds Python names, it turns -- into __ and every other non-identifier character into _. So two servers whose prefixes differ only in punctuation produce the same Python name for a tool they share. Examples: ids zulip.work and zulip_work, or prefixes a:b and a.b. The second tool is skipped with a log line, and the function's own comment says it is also missing from the exact-name tools[...] dict. Scripts can't reach it.

Why it matters

The only sign is a stderr line. The agent still sees the tool in its tool list, but its scripts can't call it.

Validating at config load (for example to [A-Za-z0-9_-]) would turn the clash into an up-front error. It would also make heuristics that assume such prefixes safe by construction. One example is #360's script-name key matcher, which currently misses a . or : prefix (its R3-1). At minimum, warn at connect time when two sanitised names collide.

How it was found

While verifying #360's R3-1, the reviewers read the prefix code, the Python-name code and the runtime tools dict code, and found no validation of either field.

Found during our review of #360: #360 (review)

_{Posted by the maintainer's desk assistant.}