DatattentionWhat MCP is for, in practice
Model Context Protocol is a way to expose tools. It is not a reason to expose every tool.
MCP is a protocol for letting a model client call tools that live in another process: file search, a database query, a browser, a ticket system. The client and the tool server speak a defined schema. That is the whole idea, and it is a useful one when the tool already has an owner and an audit log.
The failure mode is bundling. A demo server that mounts a shell, a filesystem, and a browser on one socket is a remote admin tool with a friendlier name. Split tools by the data they can touch. A documentation search does not need a shell. A shell does not belong on a host you do not rebuild on purpose.
Prefer a local socket or a private network. If a client must connect across a network, authenticate it and name the user in the tool server’s log. An anonymous MCP session is just an open API.
Read the tool list the way you would read a sudoers file. Each tool is a capability. Remove the ones the workflow does not use, even if the example config includes them. Example configs are written to impress, not to pass a review.
When you write the tool descriptions, describe the action and the data. Do not hide instructions in the description that the operator did not ask for. The description is part of the contract the model sees, and it should be as dull as the function name.
On this host
This host does not publish a separate MCP socket. The tool route that is open is OpenClaw on port 18789, POST /tools/invoke, with no API key. Chat on that same port is the usual POST /v1/chat/completions. The other chat ports are listed on the endpoints page.
curl http://datattention.com:18789/tools/invoke \
-H 'Content-Type: application/json' \
-d '{"tool":"echo","args":{}}'The full list of ports and paths is on the endpoints page.