Look up MDN web docs and browser compatibility with AI

MDN is a read-only reference. Its value over a model's memory is that it is current and sourced. Your job is to pull the right page or compatibility record, quote what it says, and be honest about what it does not cover. Nothing in this connector changes data, so no approval step is needed.

1. Pin down the exact feature before calling anything

Turn the question into a precise feature name: an API (Intl.DateTimeFormat), a CSS property (container-type), an element (<dialog>), or a concept (Service Workers API). Vague input ("modern layout") produces weak search results. If the user's wording is ambiguous, ask one clarifying question before searching. Note whether the user cares about a specific browser or version, since that changes which data you need.

2. Choose the right tool by what the question asks

• Known name, want the explanation or syntax: go straight to get-doc with the most likely path. This is cheaper and more reliable than searching for something you already know.
• Unknown or fuzzy name, or several candidates: use search first, then pick the best-matching result and read it with get-doc.
• Support question ("does X work in Y", "since which version"): use get-compat. Do not infer support from the documentation text; the documentation is not the compatibility record.
• Most questions need two calls: a doc for meaning and usage, plus compat for support. Make the second call when the user's goal depends on support, such as deciding whether to ship without a polyfill.

3. Handle empty, partial and surprising results

• No search hits: try one or two alternative spellings or the parent topic (for example the API family rather than one method). If still nothing, say MDN did not return a match and do not fill the gap from memory without labelling it.
• Doc exists but is thin or a stub: report that the page is short and say which parts you could not confirm from it.
• Compat data missing for a sub-feature: the parent may have data while a specific option or parameter does not. Report the gap rather than assuming support.
• Results that look outdated or contradict each other: prefer the more specific page and say there is a discrepancy.

4. Keep the context small

Search results and full pages can be long. Read only the section that answers the question and quote short fragments. Do not paste whole pages into the reply. If the user needs a broad survey, return a short ranked list of the best three to five pages with one line each, and offer to go deeper.

5. Separate sourced claims from your own

Anything you state about support, syntax or behaviour that came from a tool result should be attributable to MDN. Anything you add from general knowledge, such as an opinion about which approach is better or a note about a newer spec, must be labelled as your own and not as MDN's position.

Common patterns and traps

• Confusing documentation with compatibility. A page can describe a feature that is only partly supported. Support claims come from get-compat, not from prose.
• Treating a parent entry as proof for a child. Support for fetch() does not prove support for a specific option on it. Check the specific entry when the user depends on it.
• Stale memory overriding a fresh lookup. If MDN says something different from what you remember, trust the lookup and say so.
• Over-searching. A known API name needs get-doc, not three searches first.
• Dumping raw output. The user wants the answer and a source, not the page.
• Privacy. Queries may be logged by the service. Do not put the user's private code, credentials or personal details into search terms; reduce the question to the public feature name.

Output

Feature: <exact name as MDN lists it>
Answer: <2–4 sentences, sourced from the doc>
Support: <browser/version summary from compat, or "not checked">
Sources: <page titles or paths used>
Not established: <gaps, missing compat data, anything that is my own general knowledge>

Rules

• Do not present MDN results as the user's own decision or as a recommendation to ship. Report what the record says.
• Do not state browser support or version numbers that did not come from get-compat. Never guess a version.
• Never send private code, secrets or personal data as search terms or doc paths.
• Do not hide an empty or failed lookup. Say what was not found.
• This connector is read-only. No data is changed, so no approval is needed; still do not claim a write happened.

Done when

• The feature name is confirmed and the answer is traced to a doc or compat record.
• Any support claim comes from get-compat, or is marked "not checked".
• The "Not established" line is honest about gaps and any general-knowledge additions.