←back to thread

Tools: Code Is All You Need

(lucumr.pocoo.org)
313 points Bogdanp | 1 comments | 03 Jul 25 10:51 UTC | HN request time: 0.331s | source
Show context
pamelafox ◴[03 Jul 25 16:36 UTC] No.44456806[source]▶
Regarding the Playwright example: I had the same experience this week attempting to build an agent first by using the Playwright MCP server, realizing it was slow, token-inefficient, and flaky, and rewriting with direct Playwright calls.

MCP servers might be fun to get an idea for what's possible, and good for one-off mashups, but API calls are generally more efficient and stable, when you know what you want.

Here's the agent I ended up writing: https://github.com/pamelafox/personal-linkedin-agent

Demo: https://www.youtube.com/live/ue8D7Hi4nGs

replies(1): >>44457889 #
arkmm ◴[03 Jul 25 18:28 UTC] No.44457889[source]▶
This is cool! Also have found the Playwright MCP implementation to be overkill and think of it more as a reference to an opinionated subset of the Playwright API.

LinkedIn has this reputation of being notorious about making it hard to build automations on top of, did you run into any roadblocks when building your personal LinkedIn agent?

replies(1): >>44459201 #
1. zahlman ◴[03 Jul 25 21:07 UTC] No.44459201[source]▶
... Ah, reading these as well as more carefully reading TFA, I understand now that there is an MCP based on Playwright, and that Playwright itself is not considered an example of something that accidentally is an MCP despite having been released all the way back in January 2020.

... But now I still feel far away from understanding what MCP really is. As in:

* What specifically do I have to implement in order to create one?

* Now that the concept exists, what are the implications as the author of, say, a traditional REST API?

* Now that the concept exists, what new problems exist to solve?