The Design Principles
This is a member-only chapter. Log in with your Signal Over Noise membership email to continue.
Log in to readModule 5 · Section 2 of 6
The Design Principles
One server per domain. Don’t install two different calendar servers. Don’t install a file search server and a separate code search server if they’re solving the same problem from different angles. Each domain should have a single, authoritative server. When you find a better option, replace rather than supplement.
Prefer narrow over broad. A server with five focused tools is better than a server with twenty that happen to touch the same service. Narrow tools have clearer use cases. Claude can choose between them more confidently. You can reason about what they’ll do more easily.
Tools should do one thing. get_events_for_date_range is a good tool. get_events_and_summarise_and_create_followup_tasks is not. Composition belongs at Claude’s level — give it the primitives and let it combine them. If you find yourself building complex logic into a tool, split it into smaller tools.
Name tools to avoid ambiguity. If you have a file server and a database server both with a search tool, Claude will guess which to use based on context and sometimes guess wrong. Prefix with the domain: fs_search, db_search. Or use different verbs: search_files, query_database. Ambiguity in tool names causes errors that are annoying to debug.