A developer builds an MCP server that wraps a legacy SOAP API. The SOAP API has 200 operations. The developer considers exposing all 200 operations as individual MCP tools vs. implementing 15 composite tools that combine related SOAP calls into semantic operations. From a Claude agent usability perspective, which approach is superior and why?

MCP tool selection quality degrades as the tool count increases, because Claude must reason about which of many similar-sounding tools best matches the user's intent. SOAP APIs often have fine-grained, implementation-specific operations (CreateCustomerRecord, AddCustomerAddress, SetCustomerType, CreateCustomerIndex) that map to a single semantic operation ('create a customer'). Composite tools that encapsulate these into create_customer(name, address, type) align with how Claude reasons about tasks — in terms of business intent, not API internals. The composite tool handles the multi-step SOAP coordination internally. Exposing all 200 individual tools creates a tool selection problem where Claude must understand SOAP implementation details to choose correctly among nearly identical-sounding operations, and the claimed flexibility comes at the cost of higher selection error and more brittle reasoning. Fine-grained control does not prevent wrong assumptions; it shifts the burden to Claude to sequence operations correctly. The hybrid approach that exposes 200 tools but groups them with consistent naming prefixes reduces confusion through naming conventions but does not reduce cognitive load from 200 tool options. Restricting Claude's access at runtime to 10 tools per request based on intent classification approximates composite tools through dynamic injection but adds orchestration complexity without the semantic clarity benefit. The superior approach is the 15 composite semantic tools, because each composite tool encapsulates a complete business operation that maps to Claude's reasoning about intent rather than implementation details.