Border

Check whether a browser would allow a cross-origin API call (CORS)

border_check_cors

Read-onlyIdempotent

Use when the user hits a CORS error ("blocked by CORS policy", "No 'Access-Control-Allow-Origin' header", "preflight", "Failed to fetch" from a frontend) or is about to call a public API from browser code (React, Next.js, Vue, a browser extension page) and asks whether it will work (signals: "CORS", "works in Postman but not in the browser", "preflight 401/404", "Access-Control-Allow-Headers", "withCredentials", "credentials include"). Sends the browser's own preflight (OPTIONS with Origin, Access-Control-Request-Method and -Headers) to the live API and, for GET and HEAD, the request itself with the Origin header, then applies the Fetch standard CORS rules as Chrome implements them. Returns verdict (allowed, blocked, preflight_passed, incomplete, same_origin, unreachable), the exact Chrome console error, which step fails (preflight or response) and why, whether a preflight is needed and why, the CORS headers the server sent, warnings (missing Vary: Origin, a server that echoes any origin with credentials, unreadable response headers, Authorization covered only by *), the exact response headers that fix it, and curl commands to reproduce. Example: {"url":"https://api.example.com/v1/items","origin":"http://localhost:3000","method":"POST","headers":["Content-Type: application/json","Authorization"],"credentials":true}. Limits: public http/https APIs on ports 80 and 443 only (localhost, private and staging servers go through border_check_cors_headers with pasted curl output); never sends POST, PUT, PATCH or DELETE (those get the preflight checked only) and never sends header values for Authorization or keys; a server can answer differently to a real browser session.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "url": "<url>",
      "origin": "<origin>"
    },
    "name": "border_check_cors"
  }
}

Input Schema

Name	Required	Description
`url`	Yes	The API address the page calls, for example "https://api.example.com/v1/items".
`method`	No	HTTP method the page uses (default GET), for example "POST", "PUT", "PATCH" or "DELETE".
`origin`	Yes	The origin of the page that makes the request: scheme, host and port, for example "https://app.example.com" or "http://localhost:5173". A full page URL is reduced to its origin.
`headers`	No	Request headers the page sets in fetch() or axios, as "Name" or "Name: value". Values matter only for Content-Type, Accept, Accept-Language, Content-Language and Range; give names alone for Authorization and API keys. Example: ["Content-Type: application/json","Authorization"].
`credentials`	No	true when the request sends cookies: fetch credentials: "include", XHR or axios withCredentials: true. Default false.
`read_headers`	No	Response headers the page code reads with response.headers.get(), for example ["X-Total-Count","ETag"]. Checked against Access-Control-Expose-Headers.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 12, 2026

TDQS

A4.1/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is largely covered. The description adds substantial context beyond them: the enumerated verdict values, warnings (missing Vary: Origin, origin echoing with credentials, unexposed headers), and the caveat that a real browser session may differ. That extra detail is genuinely useful, but much of it reads as return-value documentation rather than behavior the agent must not assume.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The when-to-use triggers are front-loaded and the constraints close the block, so nothing important is buried. However, it is a single dense run-on paragraph mixing triggers, mechanism, return values and limits; splitting it into short labeled sections would make the same content faster to scan.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description carries the return-shape burden and does so by enumerating verdict values, failing step, CORS headers sent, warnings and remediation headers. The limits and caveats about server-side differences round it out, leaving little an agent would need to infer.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all six parameters and the baseline is 3. The description contributes an integrated example showing method, headers and credentials together and notes that only Content-Type/Accept/Accept-Language/Content-Language/Range values matter, which reinforces the schema without expanding it much.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource — sends the browser's preflight (OPTIONS with Origin and Access-Control-Request-*) plus the GET/HEAD request, then applies Fetch standard CORS rules as Chrome implements them. It is clearly distinguished from the sibling border_check_cors_headers, which is named as the route for localhost, private and staging servers.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit triggers are given with real error strings ("blocked by CORS policy", "preflight", "works in Postman but not in the browser") and named signal keywords. It also states the exclusion conditions — ports 80/443 only, localhost/private/staging goes to border_check_cors_headers — and what it will not send (POST/PUT/PATCH/DELETE bodies).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Border tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?