WriteHuman review: easy free access, a weaker reading of the source

WriteHuman's first free Standard variation was easy to obtain, but it weakened the meaning of our library report. The sentence about Wednesday visitors became difficult to understand, and the reason longer evenings might help daytime workers changed into a claim about people who cannot visit on weekends. The draft needed factual repair before stylistic polishing.

WriteHuman also has official REST API and MCP documentation. Those are useful integration findings, but they do not make the browser output more accurate. We verified the documentation separately and did not run a paid API request or connect an MCP client.

The WriteHuman tool profile contains the actual screenshots, full source and output, parameter table and dimension scores from October 27, 2026. This article explains the first variation we retained and the distinction between its web request limits and developer offerings.

The free Standard test

We pasted the unchanged 93-word benchmark into the public editor. Standard was selected, and the input counter showed a 250-word limit. The complete rewrite returned without requiring registration or payment.

The result interface offered two variations and a free retry. We retained the first variation rather than selecting the one with the most favorable appearance or vendor score. That keeps the comparison consistent with products that returned only one draft.

The interface displayed scoring messages and invited another attempt. We kept the first variation anyway, then checked it against the source. A score beside the result cannot tell us whether its sentence about Wednesday visitors still makes sense.

The selected mode matters. We did not test Enhanced or a paid plan, and we did not establish how additional variations behave under those options. The score is a review of the captured Standard guest result, not an average across every configuration.

The opening lost an explicit part of the setup

The source describes a four-day schedule tested over six weeks. WriteHuman retained the six-week duration, Wednesday closure, longer Monday and Thursday hours and unchanged 40-hour weekly total. It did not explicitly retain the four-day label.

A reader might infer a reduced opening week from the closure, but the source states the four-day schedule directly. Keeping that explicit detail would make the rewrite more complete and reduce the need for inference.

The sentence was also longer and more administrative than the original. It packed the schedule into a construction about implementing an arrangement, where a direct statement about testing it would have been clearer. The change did not add evidence or a useful perspective.

This is a moderate completeness issue rather than the largest error in the output. Much of the operational setup survived. The more serious changes occur in the account of Wednesday visitors and the explanation of who might benefit from longer evenings.

The Wednesday sentence became unclear

The source says Wednesday visitors had to change their plans. WriteHuman's result instead says Wednesdays lost their only visit day. The sentence is difficult to interpret because it assigns the loss to the day rather than to the people affected.

The underlying idea can be guessed from the original, but a finished report should not depend on that rescue. A reader encountering only the rewrite may not know whether the library closed, whether a group lost access entirely or whether some other scheduling restriction is intended.

This is both a readability problem and a fidelity problem. The factual consequence of the closure is no longer stated clearly. It also makes the report sound less natural at a point where the source was straightforward.

We would replace the clause with a direct description of visitors rearranging their plans. Simply correcting one word would be less reliable than restoring the original relationship between the closure and the affected people.

Daytime access became weekend availability

The original suggests longer evenings may help people who work during the day. The output describes a benefit for people who work and cannot visit during the weekend. That changes the scheduling condition behind the proposed benefit.

Evening access is relevant to someone occupied during the day. Weekend unavailability is a different constraint, and the source says nothing about it. The rewrite therefore introduces a new explanation while dropping the specific one it was given.

The sentence remains plausible enough to pass a quick skim. That makes it a useful example of why factual review must look beyond obviously strange wording. A fluent sentence about the same broad topic can still describe a different group or reason.

We would restore the daytime-work condition and keep the possibility conditional. No new evidence was supplied to justify a stronger or different account of who benefits from the trial.

The figures and several caveats remained

WriteHuman kept the attendance increase from 1,200 to 1,320. It did not change the values or add a new percentage. The output also retained the statement that productivity was not measured, avoiding a claim that staff efficiency had been proven to improve.

The phrase "less distractions" needs the comparative "fewer". The choice of "distractions" for "interruptions" also shifts the wording slightly, though the surrounding meaning remains recognizable. The statement that productivity was not measured survives explicitly.

The ending kept the survey, cost analysis and winter repeat. It also retained the possibility that travel habits could differ in winter. The output did not invent a specific seasonal direction or remove the follow-up entirely.

These preserved details explain why the result is not scored as a complete factual failure. It is still recognizably the same report, with several important elements intact. The problem is that the altered clauses change parts of the explanation and require targeted repair.

Readability and the cost of repair

The output consisted of complete sentences and was broadly understandable. It did not add a long assistant preamble, and the paragraph was not dramatically expanded beyond the source. Those are practical advantages when moving a result into another document.

Several local phrases were awkward, however. The Wednesday clause is the clearest example, and the wording around fewer distractions also needed attention. The opening was more cumbersome than the original's direct description of a trial.

Before choosing which stylistic changes to keep, we would restore the four-day detail, explain what happened to Wednesday visitors and return the benefit to people who work during the day. Those repairs are necessary to tell the same story as the source.

A humanizer can still be useful when it supplies a draft with some worthwhile phrasing. Here, the amount of repair reduces that benefit. The source was already clear, and several of the tool's new choices would need to be undone rather than refined.

Variations, retries and change inspection

The interface's multiple variations and free retry can help a user explore alternatives. We did not use them to improve the published score. The first variation remains the evidence for this review.

Another variation might avoid these errors, but we did not compare it. This review shows the editing work left by the first saved draft. It gives no estimate of how many retries a user would need to find a better one.

We did not verify a word-level insertion-and-deletion diff or a line-by-line change display in the tested humanizer workflow. The site's separate detector presentation includes sentence-oriented information, but that is not automatically a rewrite diff.

A Copy action was available. Copying the text is a useful final step only after checking it; it does not establish that the result is ready to publish. The profile supplies the complete original and output so the changed relationships can be inspected directly.

Web pricing is based on requests and input size

The official price table lists three free requests per month. The guest editor's visible cap was 250 words per input, which was sufficient for our sample. We did not exhaust the free allowance to test renewal or retry accounting.

Under monthly billing, Basic showed $20 for 80 requests per month with up to 600 words per request. Pro showed $29 for 200 requests and up to 1,200 words per request. Ultra showed $59 for an advertised unlimited number of requests with up to 3,000 words per request.

The annual totals shown were $144, $228 and $468 respectively. Those correspond to lower displayed monthly equivalents, but they are annual commitments. We did not purchase any subscription or validate checkout charges.

Requests and words per request are separate constraints. A user with many short paragraphs may reach the request count first; someone with longer documents may hit the input cap. It would be misleading to convert those plans into a guaranteed monthly word volume without knowing how the person actually uses them.

The REST API has its own terms

WriteHuman's official API material describes programmatic humanization and separate word-based pricing. That is not the same allowance as a web plan's request count. A developer should check the API plan rather than assume that browser requests can be reused as API credits.

We verified the existence of the humanizer interface and its public documentation. We did not submit a live request, compare API output with the browser result or measure error handling and response time. The API tag therefore means documented availability, not end-to-end reliability testing.

The browser score also does not tell a developer whether an API request uses the same configuration or returns similar wording. That would require a recorded request with its settings and output, which this test does not include.

The writing defects shown in this test would still matter in automation. An API makes it easier to obtain text, but it does not eliminate the need to check whether the beneficiary group and visitor consequence remain faithful to the source.

MCP is documented, with plan requirements

WriteHuman also documents an OAuth-based MCP connector for supported clients. The official MCP page states that access is included with Pro, Ultra and API subscriptions. We use that explicit requirement rather than assuming every visible mention of MCP means free access.

The documentation gives the MCP path /api/mcp/v1 and an OAuth sign-in flow. We did not connect a client, grant access or invoke a tool. The MCP tag records those official instructions, not a completed client test.

No downloadable product-specific agent skill was verified. An MCP connector and a skill are different interfaces, even when both can be used by an agent. The directory keeps their tags separate so a reader can filter for the capability actually needed.

The integration dimension earns 8/10 for the documented REST and MCP offerings. Meaning and facts earns 5/10 for the saved browser paragraph. The separate scores make the trade-off visible: access documentation is strong, while the actual rewrite still needs repair.

Our recommendation

WriteHuman is easy to inspect through its free Standard workflow, and its official developer documentation is more concrete than a simple API menu label. The first browser variation in this test nevertheless needed factual and grammatical repair.

We would restore the four-day setup, rewrite the Wednesday-visitor clause and replace the weekend explanation with the original daytime-work condition. We would then check the remaining paragraph against the source before copying it elsewhere.

For a writer, the first variation leaves a clear repair list and no evidence that Enhanced would eliminate it. For a developer, the documentation supports further evaluation but still needs a live test under the appropriate plan. Neither use should treat this review as a detector-bypass or plagiarism-clearance result.