THE MODEL CONTEXT PROTOCOL (MCP) AND TOOL STANDARDS

LIMITATIONS AND KNOWN WEAKNESSES No standard is perfect, and a certified harness engineer must know the limits. Context cost. Every connected tool adds its description to the model's context, so connecting many servers can crowd the limited reading space, as discussed in Chapter 14. Quality varies. Anyone can publish a server, and some are poorly designed, with vague descriptions, bad error messages, or non-idempotent actions, so the design lessons of Chapter 15 apply to them too. Security exposure. Connecting an agent to many outside servers expands what attackers can reach. Risks include tool poisoning, in which hidden instructions in a tool's description try to steer the model, and malicious or compromised servers. These are covered in depth in Part Nine, so here we only flag them. Complexity of operation. Network servers raise questions about authentication, scaling, session handling, and versions that stay compatible. Fast change. The standard and its features are still evolving, so integrations need to be tested whenever you upgrade. Not everything needs it. For a tiny agent with two simple tools, writing plain functions directly is often simpler than adding a protocol. MCP shines when you need many integrations, reuse across products, or a shared ecosystem.