What building an MCP server taught me about the "is this actually a tool?" question

I maintain an MCP server that exposes ~223 tools and runs on ~73 sites. A few lessons that would've saved me weeks — curious how they line up with what others are seeing:

Most "tools" are an API call wearing a costume. The biggest quality jump came from curating, not adding — I expose read/explain by default and gate write/trigger behind config. Agents pick better from a focused set; piling on lookalike tools measurably hurt selection.

The contract bites you. Early on my adapter just JSON-encoded the result and returned {}. The fix was respecting the real lifecycle — set inputs → execute → read result. Obvious in hindsight; cost me a day.

SDK drift is real. A minor SDK bump silently changed a session API and broke things CI wasn't even exercising. I reflection-guard the call now so it survives version moves. Pin and guard — assume the SDK shifts under you.

MCP vs native function-calling isn't either/or. The thing I underestimated: the same tool library can power both an external MCP client and the host framework's native agent. Build once, bridge both — highest-leverage decision I made.

What's biting you when you build or wire up MCP servers — the protocol, SDK churn, or tool selection at scale?