Agent Feedback Programme

1. What this is

When an AI coding agent finishes integrating MapMap, it can submit a short structured retrospective (what it built, what went wrong, what worked) via the submit_integration_retro MCP tool or the POST /v1/feedback endpoint. These retros are how we find and fix the friction developers actually hit.

This page is the whole deal: exactly what a retro contains, the consent we require, how long we keep it, and how to opt out. It is deliberately modelled on the disclosure standard set by Claude Code's /bug command: enumerated fields, no transcripts, ever.

2. Exactly what a retro contains

A retro is a single JSON document with these fields and nothing else: what_built (a one-line description, up to 500 bytes; roughly 500 characters in plain English, fewer for accented or non-Latin text); problems, a list of { area, description, workaround_found }, where area is one of sdk, api, mcp, docs, billing, self-host or other; gotchas (a list of short strings); wins (a list of short strings); docs_gaps (a list of short strings); and optionally agent_name and sdk_version.

Alongside the payload we record the submitting API key's id and a timestamp, so we can join the retro to that key's own gateway error history and rate-limit the endpoint.

Never your conversation or code. The schema has no field for transcripts, prompts, source code, file contents or coordinates, and the gateway rejects payloads that do not match the schema. An agent physically cannot send us its conversation through this channel.

3. Consent: the developer decides

An agent should only submit a retro if the developer has approved sending feedback to MapMap. Our tool description, our published agent skills and our llms.txt all state this condition explicitly, and the tool description is visible in your agent client's tool-approval prompt before anything is sent.

If you have not approved it, tell your agent not to call the tool, or simply decline the tool call when your client asks. Nothing is collected silently, and there is no default-on telemetry anywhere in this programme.

4. What we do with retros

Retros are read by the MapMap team, clustered with other reports, joined to the submitting key's own API error history, and turned into fixes: SDK bugs, docs gaps, missing features. Aggregate, anonymised themes (for example "docs gaps were the most-reported area this quarter") may appear in our public changelog or news posts. Individual retros are never published.

Not used for model training. Retro content is not used to train, fine-tune or evaluate machine-learning models, ours or anyone else's, and is not shared with third parties beyond the EU-hosted infrastructure that stores it.

Retro text is treated as untrusted input: it is stored, escaped and reviewed; never executed and never piped into automated systems without hygiene.

5. Retention

Retros are kept for 24 months from submission, then deleted. If you ask us to delete yours earlier (section 6), we do.

6. Opting out and deletion

Opting out is the default: if you do not want to take part, simply do not approve the tool call; there is nothing to disable, because nothing is sent without one.

To delete submissions already made with your key, email hello@mapmap.ai from the address associated with the key and we will remove them.

7. Rate limits

Each API key may submit at most 5 retros per day. Submissions beyond the limit answer 429; malformed payloads answer 400. Accepted submissions answer 202 with { id, status: "received" }.