MCP Explained | What, Why and How

CJ explains Model Context Protocol through weather, web-search, documentation, and debugging examples. The central mechanism is a loop: the model requests a tool, the host executes it, and the returned data becomes context for the model's next response.

Based on the saved English auto-generated captions; no original-audio verification was performed. Client settings, feature support, and free-tier references describe July 2025. These are tutorial demonstrations, not independent accuracy or performance benchmarks; the Sentry segment explicitly identifies Sentry as Syntax's sponsor.

Key points

• The host executes tools; the model requests them. CJ first distinguishes a standalone model from the application around it. Alongside instructions, history, and the user prompt, the application supplies available-tool definitions. In his weather example, the model requests coordinates for a place, receives the result through the host, then requests weather using those coordinates. MCP standardizes how compatible clients discover and invoke server capabilities, rather than giving the model itself a network connection 03:06–09:39(opens in a new tab).
• Descriptions can explain prerequisites, while schemas define inputs. CJ's weather demo asks for the user's location before calling a coordinate tool, then uses its output in a weather request. The implementation registers names, descriptions, Zod input schemas, and callbacks. A description tells the model to ask for a missing location or use the coordinate tool first; the callbacks call OpenStreetMap's Nominatim and Pirate Weather and return JSON. This demonstrates a tool chain, not guaranteed adherence to every description 09:39–11:41(opens in a new tab), 13:30–17:22(opens in a new tab).
• Local tools do not imply a local model. In the standard-input/output setup, Claude Desktop starts CJ's Node process and communicates with it locally; the model requests still go to Anthropic. Configuration supplies the executable, arguments, and environment variables needed by the tool. For a hosted currency server, CJ instead uses mcp-remote to bridge the remote endpoint into a local stdio connection, after resolving his Node-version setup issues 17:22–23:17(opens in a new tab).
• An SDK handles the protocol, but hosting remains your responsibility. CJ contrasts his local server with Wes's Cloudflare-hosted currency server: both register tools, while the hosting SDK handles remote protocol details. Remote deployment can keep implementation and credentials on the server and spare users a local checkout, but the operator bears the hosting costs 12:38–13:30(opens in a new tab), 22:18–25:16(opens in a new tab).
• Test the tool directly before testing the model's use of it. MCP Inspector provides a dashboard to list tools, enter arguments, and inspect results without repeatedly restarting a chat client. CJ tests a search tool and a URL-fetching tool that converts pages to Markdown, then demonstrates the model chaining search and page retrieval. On a second question, he must explicitly ask it to search; having a tool available does not mean it will automatically use it 24:19–29:15(opens in a new tab).
• Retrieve relevant documentation instead of relying only on model memory. With Context7, CJ first resolves a library identifier and retrieves Pirate Weather documentation, then asks the editor to write the API call with the required options. He explains that topic filtering and response-size limits can keep documentation from consuming the whole context window. His successful examples show the workflow's potential, not a general guarantee of correct generated code 30:16–33:10(opens in a new tab).
• Purpose-built tools can return more targeted data than general search. CJ's Denver-events server calls schedule endpoints discovered through browser network inspection, returning structured event data without navigating the public pages. He demonstrates a Rockies schedule query through Gemini CLI to show that a coding-oriented client can also use noncoding tools. His speed comparison is an observation, not a timed benchmark 34:15–38:17(opens in a new tab).
• A debugging integration supplies evidence and proposed fixes, not proof of correctness. In the sponsored Sentry example, CJ retrieves project issues in Cursor, requests Seer analysis, and applies a proposed route change. He then asks Context7 for framework documentation to check the approach. The demonstrated sequence ends with the editor change and the model's assessment; the captions do not establish an executed regression test or a deployed fix 38:17–42:09(opens in a new tab).

Full video: https://www.youtube.com/watch?v=1FqiNnOsrgM(opens in a new tab)