Anthropic MCP Directory — Follow-up review for v1.4.0

[bryan-anthropic]

Hi from Anthropic 👋

Following up on the previous review thread (#10) — we revisited Local Falcon MCP after seeing v1.4.0 land. We're tracking a couple of items from the v1.4.0 build before we update the listing.

Required to update the listing

Version mismatch in the running server

We observed package.json reports 1.4.0 but the server's initialize response returns version: "1.3.1". The string is hardcoded in dist/server.js:28:

const server = new McpServer({
    name: "Local Falcon MCP Server",
    version: "1.3.1", // Keep in sync with package.json
    ...
});

The comment notes the intent — could you bump the literal to 1.4.0 (or read it from package.json at build time) so the protocol-reported version stays in sync with releases?

Worth considering

API key transport

We observed all calls to api.localfalcon.com/v1/* send the API key as a URL query parameter (url.searchParams.set("api_key", apiKey) — 22 call sites in dist/localfalcon.js). Transport is HTTPS so the value is encrypted in flight, but URL parameters can show up in upstream access logs and any TLS-terminating proxies between the client and the API.

If the Local Falcon REST API supports header-based authentication (e.g. Authorization: Bearer <key> or X-API-Key), moving credentials into the header would reduce exposure on logging surfaces. If header auth isn't currently supported on the API side, that's a server-side change rather than something this MCP can fix on its own — happy to leave it as-is and re-evaluate if/when the API exposes a header-based path.

Tighter input validation on a few tool parameters

The MCP tool definitions in dist/server.js already use Zod with strict .enum() constraints on gridSize, measurement, platform, and a regex on reportKey — that's good. A few parameters could be tightened the same way:

• placeId is z.string() — Google Place IDs follow a ChIJ... shape; a regex would catch malformed input before it hits the API.
• lat / lng are z.string() — coercing to number with z.coerce.number().min(-90).max(90) (and ±180 for lng) would fail fast on bad input rather than waiting for a 400 from the API.
• radius is z.string() — the description says "0.1 to 100", so z.coerce.number().min(0.1).max(100) would enforce that.

These are enhancement suggestions, not blockers.

---

For context on the broader MCPB extension format (manifest fields, user_config, sensitive: true for credentials, etc.), the developer guide is here: https://github.com/anthropics/mcpb#readme

Let us know once the version sync is in place and we'll re-run the review.

Thanks!

[WeAreLocalFalcon]

Hi Bryan,

v1.4.1 shipped today, addressing both items:

• Version sync: server.ts now reads from package.json at startup using ESM URL resolution. Drift is impossible going forward.
• Zod tightening: lat / lng / radius use z.coerce.number() with bounds (±90, ±180, 0.1–100). placeId was kept loose because the parameter is polymorphic across Google (ChIJ…), Apple, and brand-only formats — a strict regex would have rejected legitimate cases.

Release: https://github.com/local-falcon/mcp/releases/tag/v1.4.1
npm: https://www.npmjs.com/package/@local-falcon/mcp/v/1.4.1

Ready for re-review whenever your queue gets to it.

Thanks!
David