Description
As part of the move onto the single Blockscout PRO API, chain-support validation moved inside the authenticated data-fetch helpers, replacing a single upfront check. The address-info tool retrieves address metadata through a separate metadata path that does not share this validation, so for an unsupported chain it still issues an authenticated network call that is guaranteed to be wasted. This proposal extends the same chain-support check to the metadata request so no PRO API call is spent — and no latency incurred — on a chain that is known in advance to be unsupported. It is a follow-up to the PRO API data-tools migration tracked in blockscout/mcp-server#380.
Motivation
Before the migration, the address-info tool validated chain support once, upfront, before issuing any of its concurrent sub-requests. An unsupported chain failed fast with a clear "not found" signal and nothing left the server. The migration distributed that validation into the authenticated data-fetch helpers as a per-request chokepoint — a deliberate design choice so that no caller can bypass it.
The metadata request is the one authenticated request that sits outside this chokepoint. Two consequences follow:
- Wasted call. Because the tool dispatches its sub-requests concurrently, the metadata request is sent even when a sibling request fails chain validation. The overall tool result is still correct (it fails fast with a clear "not found" from the primary request), but an authenticated metadata call has already gone out — spending credit and quota and adding round-trip latency for a result that is known in advance to be irrelevant.
- Divergence from prior behavior. The pre-migration guarantee was that an unsupported chain produced no outbound traffic at all. The current behavior quietly breaks that guarantee for this one request.
Bringing the metadata request under the same chain-support gate restores the old guarantee and reinforces a consistent principle: every authenticated PRO API request shares one validation path, so none can be issued for a chain the server already knows is unsupported.
Current State
- Chain-support validation lives inside the authenticated data-fetch helpers and runs before each request, acting as a chokepoint that callers cannot skip.
- The address metadata lookup uses a separate, chain-agnostic gateway endpoint that filters by a chain query parameter. It performs the API-key check but not chain-support validation, and chain identity is carried implicitly as one of its query parameters rather than as a first-class input.
- The address-info tool issues its sub-requests concurrently. With validation now distributed per request and no single upfront gate, a failing chain check on one sub-request does not prevent the metadata request from being dispatched.
Proposed Changes
- Apply the same chain-support validation to the address metadata request that the other authenticated PRO API requests already perform, before any network call is made.
- Make chain identity a first-class input of the metadata request, so the supported-chain check and the request's chain filter derive from a single source of truth rather than an implicit query parameter.
- Preserve the existing fail-fast, clear "not found" behavior for unsupported chains, restoring parity with the pre-migration upfront-validation guarantee.
- Ensure the metadata request is short-circuited — no network call, no credit spent — whenever the chain is unsupported.
Expected Benefits
- No authenticated PRO API call or credit is wasted on address metadata for a chain known in advance to be unsupported, and no additional round-trip latency is incurred.
- Behavior matches the pre-migration guarantee: an unsupported chain is rejected before any request leaves the server.
- All authenticated PRO API requests share one consistent chain-support gate, eliminating the single path that could bypass validation.
- Lower risk of future regressions, since validation is centralized in the request path rather than dependent on each caller remembering to check the chain first.
Dependencies
This builds on the migration of all data tools onto the single PRO API base URL — blockscout/mcp-server#380 — which is where the main work of moving away from per-instance Blockscout URLs is done, and within which chain-support validation was relocated into the authenticated data-fetch helpers. This proposal is a small, self-contained refinement that closes the one remaining request path left outside that validation, and should be sequenced after that work.
Description
As part of the move onto the single Blockscout PRO API, chain-support validation moved inside the authenticated data-fetch helpers, replacing a single upfront check. The address-info tool retrieves address metadata through a separate metadata path that does not share this validation, so for an unsupported chain it still issues an authenticated network call that is guaranteed to be wasted. This proposal extends the same chain-support check to the metadata request so no PRO API call is spent — and no latency incurred — on a chain that is known in advance to be unsupported. It is a follow-up to the PRO API data-tools migration tracked in blockscout/mcp-server#380.
Motivation
Before the migration, the address-info tool validated chain support once, upfront, before issuing any of its concurrent sub-requests. An unsupported chain failed fast with a clear "not found" signal and nothing left the server. The migration distributed that validation into the authenticated data-fetch helpers as a per-request chokepoint — a deliberate design choice so that no caller can bypass it.
The metadata request is the one authenticated request that sits outside this chokepoint. Two consequences follow:
Bringing the metadata request under the same chain-support gate restores the old guarantee and reinforces a consistent principle: every authenticated PRO API request shares one validation path, so none can be issued for a chain the server already knows is unsupported.
Current State
Proposed Changes
Expected Benefits
Dependencies
This builds on the migration of all data tools onto the single PRO API base URL — blockscout/mcp-server#380 — which is where the main work of moving away from per-instance Blockscout URLs is done, and within which chain-support validation was relocated into the authenticated data-fetch helpers. This proposal is a small, self-contained refinement that closes the one remaining request path left outside that validation, and should be sequenced after that work.