get_geolocationLABSCO SUMMARY
An agent can ground an answer in where the caller actually is.
The location does not come from an IP database you have to trust — it comes from the edge node that served the request, which is the same signal EdgeOne uses to route it.
What it is
Two pieces that ship together: an EdgeOne Pages Function that pulls geolocation out of the EdgeOne request context and returns it as JSON, and an MCP server that calls that function so a model can ask for the same data.
What you get
get_geolocation— returns the location information the EdgeOne Pages Function reads from the request context- The function itself, in
functions/get_geo.ts, deployable to EdgeOne Pages from the template button in the README
Requirements
An EdgeOne Pages deployment, since the location data comes from EdgeOne's own request context rather than from a lookup service. The MCP side is mcp-server/index.ts, launched with tsx in your client config.
Setup effort
Build from source — get the source, then follow the project's own run instructions
USE CASES
01
Tailoring a reply to the visitor's region
Read the location off the request and use it to pick language, currency or opening hours without asking the user where they are.
02
Checking what your edge function actually sees
Call the tool while iterating on the Pages Function and read the JSON back, rather than deploying and tailing logs.
03
Adding location to an agent that has none
A single deployed function gives any MCP client a geolocation source it did not have before.
1 tool
Listed in project docs. Your client may show a different list.
BEFORE YOU INSTALL
What to know first
Tools you get
1 tool named in the project's documentation.
Requires
tsx on PATH
INSTALLATION
Connect your client
You clone and build this one yourself.
Server setup
Configuration file
JSON
{
"mcpServers": {
"edgeone-geo-mcp-server": {
"command": "tsx",
"args": [
"<YOUR_PATH_TO_MCP_SERVER>/index.ts"
]
}
}
}The command line the project publishes
TERMINAL
tsx <YOUR_PATH_TO_MCP_SERVER>/index.ts
