kerlenton

6 ms·

1. 1.▲
   Mcpsnoop fails CI on what your MCP server did on the wire(github.com)

   1 points by kerlenton 24d ago|0 comments
2. 2.▲
   MCP's new spec breaks latency measurement for observability tools(github.com)

   1 points by kerlenton 2mo ago|0 comments
3. 3.▲
   by kerlenton 2mo ago

   Ha, fair. tshark in a shell works fine, the only reason to wrap it is typed output and not handing the agent a raw shell.
4. 4.▲
   by kerlenton 2mo ago

   Thanks, that means a lot. Would love to hear how it goes once you try it
5. 5.▲
   by kerlenton 3mo ago

   There's nothing redacted because the header isn't collected in the first place. Under http mode, the proxy intercepts the JSON-RPC messages, but not their headers, so there's no way for the log to contain the Authorization he
6. 6.▲
   by kerlenton 3mo ago

   Maybe, but I didn't do it. Perhaps people are boosting their karma?
7. 7.▲
   by kerlenton 3mo ago

   Thanks a lot!
8. 8.▲
   by kerlenton 3mo ago

   Thank you! Showing the data in a web page should definitely be possible. But I’m not sure if this matches the original idea I had, where the tool would run in the terminal only. Why do you feel the need to show the data in a web page? Is th
9. 9.▲
   by kerlenton 3mo ago

   Thanks! Actually, there is already an MCP for Wireshark, for example https://github.com/0xKoda/WireMCP
10. 10.▲
    Show HN: Mcpsnoop – Wireshark for MCP (transparent proxy and live TUI)(github.com)

    64 points by kerlenton 3mo ago|22 comments
11. 11.▲
    by kerlenton 3mo ago

    [flagged]
12. 12.▲
    by kerlenton 3mo ago

    Makes sense. 3 generic tools + summarize first is a nice approach to sidestepping the problem of too many tools. But it looks like it shifts the chokepoint around rather than eliminating it: instead of "choose the proper tool out of ma
13. 13.▲
    by kerlenton 3mo ago

    Multiplexing the agents is clearly the first obvious pain point, but the other one I keep encountering after this is visibility: with multiple agents running, it becomes difficult to see what each of them is doing, what program did they cal
14. 14.▲
    by kerlenton 3mo ago

    The catalog approach is appropriate for MCP as well. Something I would be interested in: once you have all of your services/APIs/DBs exposed via one MCP server, the next choke point will become the model of selecting the correct t
15. 15.▲
    by kerlenton 3mo ago

    The deterministic MCP server testing without any LLM in the loop is actually pretty useful for CI. However, the issue that I run into consistently is a level above: the server can do just fine with all the scripted calls but fail in real pr
16. 16.▲
    by kerlenton 3mo ago

    A helpful place to start. One item that I would point out is that many authorities exist at the time of running the program rather than in the configuration or tool definition. So what happens on the server (e.g., what data it requests, if
17. 17.▲
    by kerlenton 3mo ago

    The approach you described to recording and replaying actions seems interesting. I went at this problem from a different perspective, though. I developed a wiretap transparent proxy that sits in the middle of the JSON-RPC traffic between th