5,215 karma · joined September 23, 2014
You're being sarcastic but this would have been the most lucrative thing Xerox ever did in its entire corporate life, by far, if it had held onto the stock. This was a really good deal in hindsight. Indeed, it would have been better to liquidate Xerox and put all the proceeds into Apple stock; I don't think anybody argues that Xerox could have made as much hay as Apple did with the technology, even in the best of scenarios. It couldn't have known that at the time, of course.
e.g. https://www.phoronix.com/review/aws-m8a-m8g-m8i-benchmarks -- m8a won virtually all of these comparisons by a wide margin. Raw performance isn't really Graviton's selling point; price-performance is.
It's surprising because we still use it today, not because it was used at the time.
> If you have a server or other device that requires automatic issuance of certificates and supports the ACME protocol, you can use our free 90-day ACME certificates on all plans.
I have done this with entire textbooks. Find a PDF and get GPT-5 to transcribe it page by page to Markdown. Costs a couple bucks and turns the agent into a wizard on that subject.
Context7, too, could easily have been a command line tool that both you and the agent can use. Even now, I don't see what MCP--specifically--brings to the table.
[1] One trick for Cursor users: put "/context/" in .gitignore and "!/context/" in .cursorignore. This will keep it out of git but still index it.
- My own "execute bash command" tool, adding output pagination, forcing the agent to choose a working directory, and working around some Cursor bugs on Windows. This avoids context explosion when a command unexpectedly returns a huge amount of text, and avoids a common agent failure mode where it misunderstands what directory it is currently in.
- SQL command execution. This can be done perfectly fine with "execute bash command" but the agent struggles to correctly encode multi-line SQL queries on the command line. You can force it to write a file, but then that's two MCP tool calls (write file, execute command) which increases the chances that it goofs it up. I simply accept an unencoded, multi-line SQL query directly via the MCP tool and encode it myself. This, again, is simply avoiding a common failure mode in the built-in tools.
I haven't needed a third tool, and if the built-in tools were better I wouldn't have needed these two, either. Everything else I've ever needed has been a bash script that both the agent and I can run, explained in the agent's global rules. It's really unclear to me what other use case I might encounter that would be better as MCP.
In theory I can see that an MCP server only launches once and is persistent across many requests, whereas bash scripts are one-and-done. Perhaps some use case requires a lot of up-front loading that would need to be redone for every tool call if it were a bash script. Or perhaps there are complex interactions across multiple tool calls where state must be kept in memory and writing to disk is not an option. But I have not yet encountered anything like this.
At work we have analysts who sometimes produce web-based dashboards for the business to consume. When we had Python folks, they used Plotly Dash and we had to host a server for them. It's a bit silly--the dashboard just accesses APIs and static data, crunches a bit, and renders some HTML. There's no inherent need for it to require its own server. There is "WebDash" [1] but I have not gotten it to work and it says it's alpha quality.
Now that we're getting into R, I don't have any path to production for dashboards. I want to avoid getting into another Plotly Dash situation where every analyst with a one-time idea ends up creating long-term IT burden. Enter WebR: now we only need to serve static files. That's a lot easier; I can serve essentially an unlimited number of dashboards from existing infra this way. Our client machines are beefy with tons of headroom and our EC2 instances are as small as possible, so shifting work from the server to the client makes sense here. I'm gonna try it and see if I've missed something.
1. High egress costs
2. No hard spending limits
Both of these were problems for the author. I don't mean to "blame the victim" but the choice of AWS here had a predictable outcome. Static documentation is the easiest content to host and AWS is the most expensive way to host it.