fix(web_fetch_exa): validate urls as URI; warn against API key in query string

[serhiizghama]

Problem

Addresses both findings raised in #334:

1. The web_fetch_exa tool schema declares urls.items as a plain string. Since the tool only ever crawls URLs, advertising format: "uri" makes client-side validation clearer and lets MCP clients flag obviously bad inputs before a round trip.
2. The README's "Enable additional tools" example places the API key in the URL query string (?exaApiKey=YOUR_KEY&tools=...). Query-string secrets are easy to leak through shell history, proxy logs, browser history, screenshots, and support bundles (CWE-598).

Solution

• src/tools/webFetch.ts: wrap the urls item type with z.string().url() so the generated JSON Schema exposes format: "uri" and the tool rejects inputs that are clearly not URLs.
• README.md: drop exaApiKey=YOUR_KEY from the multi-tool example and add a short security note recommending the MCP client's secret/header configuration (or EXA_API_KEY for the npm package).

Testing

• npm run typecheck — clean
• npm test — 82 passed (added one case verifying the schema rejects non-URL strings and still accepts valid https:// URLs)

[vercel]

@serhiizghama is attempting to deploy a commit to the Exa Team on Vercel.

A member of the Team first needs to authorize it.

[EmersonZh]

Thanks @serhiizghama — both fixes look right to me, especially the unit test addition. Appreciate you picking this up

[serhiizghama]

Hi, just checking in — the URL validation fix in webFetch.ts still isn't in main and issue #334 remains open. Happy to rebase or split out the README change if you'd prefer to keep that separate from #346/#349. Let me know how you'd like to proceed.

[serhiizghama]

Rebased on main. The only conflict was our security note landing right next to the new Exa Agent toolset docs — kept both. The URL-validation fix and its test are unchanged. Ready when you are.