Easebuzz is Poor to agents.

What we found

• —An agent trying to fetch Easebuzz's documentation programmatically is blocked outright: docs.easebuzz.in sits behind Cloudflare bot protection and returns HTTP 403 on the discovery paths (robots.txt, llms.txt, sitemap.xml, .well-known/mcp.json). Only a browser-grade/stealth fetch reaches the actual reference pages; a standard agent HTTP client gets a 'you have been blocked' page.
• —There is no purpose-built discovery surface at all: no llms.txt, no AGENTS.md across the 29-repo GitHub org, no .well-known/mcp.json, and no MCP registry listing (Glama/Smithery/PulseMCP). The only clean signal is a permissive robots.txt on the marketing domain, so Discovery scores 31/100 (F).
• —Once a page is rendered, comprehension is strong (78/100, B): endpoint pages lead with method + URL + a task-oriented purpose, every parameter carries a description plus a validation regex and explicit length/amount limits, and the payment lifecycle is documented well enough for an agent to chain Initiate Payment -> hosted checkout -> Transaction API -> Webhooks.
• —The FAQ is a standout for agent self-correction: it maps 29 error scenarios and named codes (WC0E01, RERR02-V2, 'Invalid merchant Key', 'Hash mismatch', 'Request Invalid for the merchant', duplicate txnid, IP-whitelist errors) to concrete fixes, which is exactly the recovery guidance most APIs omit.
• —A machine-readable OpenAPI spec clearly exists inside the Stoplight project (each API group exposes a stoplight.io mock server and an Export control), but it is not published at a predictable public path (no /openapi.json) and Export sits behind the bot-blocked JS UI, so an agent cannot reliably pull the full contract in one fetch.

What to change

Prioritized by impact on discoverability. You (or your docs platform) deploy these — Discry never touches your API.

1. 01Allow automated access to the docs. The Cloudflare rule that 403s bots on docs.easebuzz.in is the single biggest blocker: an agent cannot reach even robots.txt or the reference. Allow-list reputable AI crawlers or serve a public, cacheable copy so agents can read the docs at all.
2. 02Publish an llms.txt at both easebuzz.in and docs.easebuzz.in naming the core payment flow (Initiate Payment -> hosted checkout -> Transaction API -> Webhooks) with descriptive links to each API group. Highest-leverage discovery fix; flips both llmsTxt and llmsTxtQuality.
3. 03Expose the OpenAPI spec at a stable public URL (e.g. https://docs.easebuzz.in/openapi.json) and link it from the docs. Stoplight already generates it internally (evidenced by the mock servers); publishing it lets agents load the whole contract at once.
4. 04Replace empty/regex placeholder values in request code samples (e.g. amount=^[0-9.]*$) with realistic values (real-looking txnid, amount 100.00, sample email and hash) so copy-pasted requests are valid; response examples are already realistic, so this closes the gap.
5. 05Add an AGENTS.md to the primary SDK repos (paywitheasebuzz-nodejs-lib, -php-lib, -android-lib) with build/auth/hash-generation conventions, and normalize response field casing (PG_TYPE, error_Message, and camelCase statuses like preInitiated appear alongside snake_case fields).