|
2 | 2 |
|
3 | 3 | 👨💼 Great job! Now we know we've got an MCP server up and running. From here we |
4 | 4 | can start adding a bunch of different tools, resources, and more to it. |
| 5 | + |
| 6 | +<details> |
| 7 | +<summary>🦉 What the StdioServerTransport does</summary> |
| 8 | + |
| 9 | +The `StdioServerTransport` is a simple transport that allows you to connect to |
| 10 | +your MCP server using the command line. It's a good way to get started and |
| 11 | +understand how MCP servers work. |
| 12 | + |
| 13 | +The MCP Client takes the `command` and `args` you configure and spawns a child |
| 14 | +process: |
| 15 | + |
| 16 | +```ts |
| 17 | +import { spawn } from 'child_process' |
| 18 | + |
| 19 | +// these come from our config in the MCP Inspector: |
| 20 | +const command = 'npm' |
| 21 | +const args = [ |
| 22 | + '--silent', |
| 23 | + '--prefix', |
| 24 | + '/Users/kody/code/mcp-fundamentals', |
| 25 | + 'run', |
| 26 | + 'dev:mcp', |
| 27 | +] |
| 28 | + |
| 29 | +// Then the MCP client spawns a child process: |
| 30 | +const child = spawn(command, args) |
| 31 | +``` |
| 32 | + |
| 33 | +Then it listens for messages from the child process and sends them to the MCP |
| 34 | +server: |
| 35 | + |
| 36 | +```ts |
| 37 | +child.stdout.on('data', (data) => { |
| 38 | + console.log(data) |
| 39 | +}) |
| 40 | +``` |
| 41 | + |
| 42 | +This is why we use `console.error` in our server, so that the MCP Client can |
| 43 | +print it to the console without interfering with the server's output. |
| 44 | + |
| 45 | +It also listens for messages from the MCP server and sends them to the child |
| 46 | +process: |
| 47 | + |
| 48 | +```ts |
| 49 | +child.stdin.write(JSON.stringify({ jsonrpc: '2.0', method: 'ping' })) |
| 50 | +``` |
| 51 | + |
| 52 | +Other transport mechanisms exist as well, and while the code for them is |
| 53 | +different the underlying concept is the same. Just a server and client |
| 54 | +communicating with each other. |
| 55 | + |
| 56 | +</details> |
0 commit comments