fix(dns-analytics): make dns_report work on Free and Pro plan zones#351
Open
homelabchaos wants to merge 1 commit into
Open
fix(dns-analytics): make dns_report work on Free and Pro plan zones#351homelabchaos wants to merge 1 commit into
homelabchaos wants to merge 1 commit into
Conversation
…nd Pro plan zones The dns_report tool hardcoded 'responseCode,responseCached' in the dimensions list. The responseCached dimension is gated to Business plan and above, causing all requests on Free and Pro zones to fail with: Response Cached is not available for your plan. Upgrade to the business plan to see DNS analytics by responseCached. (Cloudflare API error code 1034, HTTP 403) The announcement blog for the MCP servers describes DNS Analytics as working across all domains in an account with no plan tier caveat, and the Cloudflare DNS Analytics product is offered on all plans, so this appears to be an unintended limitation. Removing 'responseCached' from the default dimensions restores the tool for Free and Pro users while keeping the responseCode breakdown for all tiers. Business/Enterprise users can still query by responseCached via the cf-graphql MCP server's dnsAnalyticsAdaptiveGroups dataset.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
The `dns_report` tool in the DNS Analytics MCP server fails with HTTP 403 on Free and Pro plan zones:
```
403 {"result":null,"success":false,
"errors":[{"code":1034,
"message":"Response Cached is not available for your plan. Upgrade to the business plan to see DNS analytics by responseCached."}]}
```
Root cause
`apps/dns-analytics/src/tools/dex-analytics.tools.ts:34` hardcodes the `responseCached` dimension, which the DNS Analytics REST API (`GET /zones/{zone_id}/dns_analytics/report`) gates to Business plan and above.
```ts
const params: ReportGetParams = {
zone_id: zone,
metrics: 'responseTimeAvg,queryCount,uncachedCount,staleCount',
dimensions: 'responseCode,responseCached', // responseCached requires Business+
since: start_date,
}
```
Every Free/Pro zone request returns 403 because of this single hardcoded dimension.
Evidence this is unintended
Fix
Remove `responseCached` from the default dimensions. `responseCode` breakdown remains available to all plan tiers.
```diff
```
Business/Enterprise users who want the cached-vs-uncached breakdown can query the `dnsAnalyticsAdaptiveGroups` dataset via the `cf-graphql` MCP server (`responseCached` is an available dimension there on Business+ accounts).
Reproduction
Reproduced on a Pro plan zone: before this patch `dns_report` returns 403 with code 1034; after this patch it returns the expected DNS report payload.
Changeset
Included `.changeset/fix-dns-report-plan-compatibility.md` marking this as a `patch` to the `dns-analytics` package, per repo conventions.
Follow-up (not included in this PR)
A richer fix would accept a `dimensions` parameter on the tool, letting callers opt into Business-gated fields when they have access. Happy to follow up with that as a separate PR if the maintainers prefer it.