A short piece of fiction, written by API Evangelist. The reader is imagined; the post, and every number and quotation from it, is real: "Can Your MCP Server Finish The Job?," Kin Lane, October 28, 2026, https://apievangelist.com/2026/10/28/can-your-mcp-server-finish-the-job/
Dalia maintained the MCP server for her team's billing tools, and she read the post on a Wednesday evening with the server's tool list open in another window. She told herself she was only checking.
The tools were get_invoice, list_invoices, find_customer and draft_reminder. Every one of them could read, and one of them could compose. She had been proud of that, because nothing in it could get her in trouble.
Then she reached the line about the email connector that will draft a message but not attach the file or send it. She winced, because that was her server. A collections agent could write a polite reminder about an overdue invoice, and then a human had to open the billing app and press the button.
She disagreed with part of it. The post says the last step is the job, and that everything before it is the cheap, safe part. But she had chosen not to build the sending tool, on purpose. Finance had asked for exactly that. A reminder that goes to the wrong customer cannot be recalled, and she did not think the post gave that worry enough weight. It did say a terminal action should come with confirmation and idempotency. That was fair, she thought, but it was also a lot of work to say in one sentence.
The numbers stung more. The author had looked at 1,350 live, hosted MCP servers and found that 438 had no tool whose name suggested it changed anything. She felt briefly defended, since she wasn't alone. Then she saw that 648 of them had at least one tool that completes something, and she felt like part of the smaller group. The post called its counts a name-based reading and told readers to treat it as a direction. She respected that, and she also noticed it didn't let her off.
What bothered her most was the sentence about a server that drafts and can't send being a preview of the product, not the product. She wasn't sure it was fair, and she couldn't say it was wrong.
She did not add a send tool that night. That would have been a reaction, and the post itself asked for something more careful than a reaction. It said to write down the three to five jobs people actually use the product for, each ending in the verb that finishes it. She opened a blank note and wrote the first one: send a payment reminder for an overdue invoice. Then she stopped, because the second one was harder to name, and she wanted to ask the support team before guessing.
Then she did the one part of the advice that cost nothing. The post said that if the server stops short, it should say so in the server instructions and in the tool descriptions, in plain words, and say where the rest happens. She opened the instructions file and added a sentence telling the agent that this server drafts reminders and does not send them, and that sending happens in the billing app. She changed the description of draft_reminder to match.
She ran the first job through the agent once, from the first step to the end, as the post suggested. This time the agent told the user up front, before drafting anything, that someone would need to send it themselves.
It wasn't the fix the post wanted, and she knew that. She saved the note with its single job in it, and put a reminder on her calendar to bring the sending question to finance on Monday.