A 311 MCP suite exposes lookup_case and get_ticket with near-identical one-line descriptions, so Claude misroutes calls. What should architects fix first?

When a 311 MCP suite exposes lookup_case and get_ticket with near-identical one-line descriptions, Claude misroutes because descriptions are the primary selection signal among similar tools. Architects should first rewrite each description to differentiate purpose, inputs, outputs, and boundaries—e.g., case lifecycle lookup versus ticket retrieval—so resident-service agents choose correctly.

Differentiated descriptions work because the model matches user intent to tool prose, not to hidden implementation details. Clear contracts (when to use, required IDs, what is returned, what is out of scope) reduce cross-calls that create wrong 311 updates or confuse residents with mismatched status language.

Adding more duplicate tools so the model has more similar choices increases entropy and worsens misrouting. Removing all descriptions and relying on tool names alone strips the main selection channel; names rarely encode inputs, outputs, and civic boundaries. Forcing every request through both tools on every turn regardless of need doubles latency, doubles side-effect risk, and still fails to teach the agent which call is appropriate.

Exam caveat: renaming alone without rewriting descriptions may be insufficient if the new names still lack purpose and boundary detail. Operational check: present identical resident intents that should hit only lookup_case or only get_ticket and confirm selection accuracy rises after description differentiation.