Add badge for mcp-customs to README.md

[mcpcustoms]

Ran your server through mcp-customs (https://github.com/mcpcustoms/mcp-customs), a free offline scanner I built that checks MCP servers for common security risks before install. It came back clean — 94/100.

Wrote up the full methodology (and where the tool got things wrong on other servers) here: https://dev.to/mcpcustoms/we-scanned-12-popular-mcp-servers-the-most-interesting-finding-was-our-own-false-positives-kcf

Adding the badge is obviously optional — totally fine to close this if you'd rather not, no hard feelings either way.

[greptile-apps]

Greptile Summary

This PR adds an mcp-customs scan badge to the README. It changes:

• Adds a new badge in the top README badge row.
• Links the badge to the mcpcustoms/mcp-customs repository.
• Uses an HTML anchor and image to match the surrounding badge markup.

Confidence Score: 5/5

This looks safe to merge.

• No blocking issues found in the changed code.

_{Reviews (2): Last reviewed commit: "Update mcp-customs badge link in README" | Re-trigger Greptile}

[greptile-apps]

The badge label bakes in a point-in-time score (CLEARED_94%2F100). If the scanner is re-run with updated rules or its scoring model changes, the displayed score becomes stale and misleading. Consider a dynamic Shields.io endpoint driven by the tool's own API/badge URL if one is available, or at minimum document that the score is as-of a specific date.

Prompt To Fix With AI

This is a comment left during a code review.
Path: README.md
Line: 8

Comment:
The badge label bakes in a point-in-time score (`CLEARED_94%2F100`). If the scanner is re-run with updated rules or its scoring model changes, the displayed score becomes stale and misleading. Consider a dynamic Shields.io endpoint driven by the tool's own API/badge URL if one is available, or at minimum document that the score is as-of a specific date.

How can I resolve this? If you propose a fix, please make it concise.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

[mcpcustoms]

Good point — right now mcp-customs is CLI-only with no live registry, so badges are necessarily a point-in-time snapshot. A dynamic Shields.io endpoint is exactly the kind of thing I'd want once there's a hosted lookup service behind it. For now I'll note the scan date if that's useful — happy to add "(scanned 2026-06-19)" to the badge text if you'd prefer that over a bare score.

[greptile-apps]

That context makes sense — a point-in-time score with an explicit date is a fair and transparent approach. Adding (scanned 2026-06-19) would address the staleness concern by making it clear the score reflects a specific snapshot rather than a continuously updated status.

Something like:

Suggested change

	[](https://github.com/mcpcustoms/mcp-customs)
	[](https://github.com/mcpcustoms/mcp-customs)

That said, this is ultimately the repo owner's call — if they're comfortable with the bare score as-is, that's a valid choice too.

Tip: You can customize Greptile's behavior for this repo with .greptile/rules.md and .greptile/config.json.