Contact

A tool that produces a wrong result, or reports a problem that is not there, is the most useful thing you can report. Include what you put in and what you expected instead — but see the warning below about what not to send.

Corrections to the written guides are equally welcome. The pages carry specific claims about how tokenisers, schemas, MCP configurations and JWTs behave, and a claim that has drifted out of date is worse than no claim. Model prices in particular change without notice; each one carries the date it was last checked, and if you spot one that is stale, saying so helps everyone who reads it next.

Requests for new tools are read, though not promised. The roadmap lists what is already being considered. What helps most is not the name of a tool but a description of the job you were trying to finish and what made it awkward, because that is the part that determines whether a tool would actually be useful.

Never include a real credential in a message. Not an API key, not a token, not a password, not a connection string, and not a JWT that has yet to expire. This applies even when the credential is the thing that went wrong.

Email is not a secure channel, and a key pasted into a thread stays in two mailboxes indefinitely. If a report needs an example, replace the sensitive part with a value of the same shape — the same length, the same prefix, obviously fake. That is almost always enough to reproduce a problem. If a credential has already been shared somewhere it should not have been, rotate it first and worry about the bug report second.

The same applies to anything covered by an agreement you have with someone else: client source code, unreleased product details, or personal information about other people. None of it is needed to describe a fault.

Requests about personal information — access, correction, deletion, or an objection to processing — can be sent to the same address, and are handled under the terms set out in the privacy policy.

One limitation is worth stating in advance rather than in a reply. There is no account system, so there is no record held against you by name or by email address. Where analytics has been accepted, the identifier involved is random, is stored on your own device, and means nothing in isolation. In most cases there would be no way to locate data as yours, and collecting more information simply to make you identifiable would be the opposite of the point.

Messages are read and answered by one person working on this independently, so replies are not immediate and no response time is promised. A clear report with enough detail to reproduce the problem will always be dealt with faster than one that needs a conversation first.

There is no ticketing system, no account to create and no queue to join. An email is the whole process.