Which integrations are available for this server?

Allows searching and retrieving details of observed Bluetooth/BLE devices from WiGLE's wardriving database.

How do I use wigle-mcp?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@wigle-mcp search for open WiFi networks in downtown Seattle" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

wigle-mcp

by thehappydinoa

Overview Schema Source Related Servers Discussions Admin

Python

Remote

wigle-mcp

An MCP server that exposes WiGLE.net wardriving lookups as tools for LLMs.

All tools are read-only. Responses are trimmed to compact summaries so agents stay within context limits and WiGLE query quota.

Tools

network_search — search observed WiFi networks by SSID, BSSID, bounding box, country/region/city, or encryption.
network_detail — look up a single BSSID; pass include_locations=true for capped sighting history.
bluetooth_search / bluetooth_detail — same pattern for Bluetooth/BLE devices.
cell_search / cell_detail — same pattern for cell towers.
user_stats — WiGLE account stats (rank, discovered network counts).
site_stats — WiGLE-wide totals (networks, locations, users).

Related MCP server: pumperly-mcp

Query etiquette

WiGLE enforces per-account daily query limits (reset midnight US/Pacific; new accounts start low). The server validates requests and ships MCP server instructions to guide agents, but humans should know the rules too:

Always filter searches. Every *_search call needs at least one filter (SSID, BSSID, geo fields, bounding box, encryption, etc.). Unfiltered searches are rejected before they hit the API.
Paginate with search_after. Responses include a searchAfter cursor. Pass it as search_after on the next page — it alone satisfies the filter requirement, so you do not need to repeat the original filters.
Prefer search over detail. One bounded search beats many per-BSSID detail calls. Keep results_per_page low unless you need more.
Locations are opt-in. *_detail returns a summary by default. Pass include_locations=true only when sighting history is needed (capped at 5 points).

On startup the server verifies credentials by calling stats/user. Missing or invalid keys fail immediately instead of on the first tool call.

Errors are returned as MCP tool errors (not success payloads with an error field). HTTP 429 responses include guidance about daily limits.

Response shape

Search results are compact summaries, not raw WiGLE records:

{
  "netid": "00:00:34:7A:67:1E",
  "ssid": "pretty fly for a wifi",
  "encryption": "wpa2",
  "trilat": 33.057,
  "trilong": -96.720,
  "country": "US",
  "region": "TX",
  "city": "Plano",
  "sightingCount": 12,
  "lastSeen": {"latitude": 33.057, "longitude": -96.720}
}

Detail responses use the same summary fields. With include_locations=true, sightingCount is accompanied by up to five locationData entries (with locationDataTruncated when more exist).

Example workflow

1. network_search(city="San Francisco", region="CA", country="US", results_per_page=5)
   → searchAfter: "3522985", results: [...]

2. network_search(search_after="3522985", results_per_page=5)
   → next page of the same query

3. network_detail(bssid="00:00:00:00:81:4E")
   → summary for one network

4. network_detail(bssid="00:00:00:00:81:4E", include_locations=true)
   → summary plus capped sighting locations

Setup

Get a free API key (Name + Token) at https://wigle.net/account, under "Your API Key".
Provide credentials via environment variables:
```
export WIGLE_API_NAME=...
export WIGLE_API_TOKEN=...
```
or in ~/.config/wigle-mcp/config.json:
```
{"api_name": "...", "api_token": "..."}
```
MCP host configs can omit env when using the config file.

Running

uv run wigle-mcp

If uv run fails because wigle-mcp.exe is locked (common on Windows when another MCP client is connected), use the module entry point instead:

uv run python -m wigle_mcp.server

Configuration

On Windows, add --no-sync to uv run args in every host config so uv does not try to reinstall the project while another client already has wigle-mcp.exe open.

Claude Code

claude mcp add wigle -- uv --directory /path/to/wigle-mcp run --no-sync wigle-mcp

Claude Desktop

{
  "mcpServers": {
    "wigle": {
      "command": "uv",
      "args": ["--directory", "/path/to/wigle-mcp", "run", "--no-sync", "wigle-mcp"],
      "env": {
        "WIGLE_API_NAME": "your-api-name",
        "WIGLE_API_TOKEN": "your-api-token"
      }
    }
  }
}

Cursor

Add to .cursor/mcp.json (project-level) or ~/.cursor/mcp.json (global):

{
  "mcpServers": {
    "wigle": {
      "command": "uv",
      "args": ["--directory", "/path/to/wigle-mcp", "run", "--no-sync", "wigle-mcp"],
      "env": {
        "WIGLE_API_NAME": "your-api-name",
        "WIGLE_API_TOKEN": "your-api-token"
      }
    }
  }
}

Development

uv sync --dev
uv run pytest
uv run ruff check .
uv run ruff format --check .

License: MIT

Available Tools

8 tools

bluetooth_detailA

Read-onlyIdempotent

Look up everything WiGLE knows about a single Bluetooth/BLE device by its MAC address, including name history and recorded sighting locations.

ParametersJSON Schema

Name	Required	Description	Default
`bssid`	Yes	MAC address to look up, e.g. 'AA:BB:CC:DD:EE:FF'

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4/5.0

Behavior4/5

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

Annotations already provide readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds context beyond annotations by specifying the scope ('everything WiGLE knows') and mentioning 'name history and recorded sighting locations.' It does not contradict annotations and provides useful behavioral insight, though it could mention potential limitations like data recency or rate limits.

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

Conciseness5/5

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

The description is a single sentence, front-loaded with the action, and contains no redundant or unnecessary words. Every part earns its place.

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?

Given the tool's simplicity (1 parameter, read-only, idempotent) and the presence of an output schema, the description is largely complete. It mentions key data returned (name history, sighting locations). Could elaborate on whether all history or recent sightings, but likely covered by output schema.

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 coverage is 100% with a single parameter 'bssid' described in the schema. The description reinforces its purpose ('by its MAC address') but adds no new meaning beyond what the schema already provides. Baseline is appropriate.

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?

The description clearly states the tool's purpose: 'Look up everything WiGLE knows about a single Bluetooth/BLE device by its MAC address, including name history and recorded sighting locations.' It uses a specific verb ('look up') and resource ('Bluetooth/BLE device by its MAC address'), and distinguishes from siblings by focusing on detailed data for a single device.

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

Usage Guidelines3/5

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

The description implies usage (when you need detailed info on a specific Bluetooth device by MAC), but does not explicitly state when to use or when not to use this tool versus alternatives like bluetooth_search. No exclusions or alternative recommendations are provided.

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

bluetooth_searchA

Read-onlyIdempotent

Search WiGLE's database of observed Bluetooth/BLE devices by name, MAC, or location.

ParametersJSON Schema

Name	Required	Description
`name`	No	Exact device name to match
`bssid`	No	MAC address to match, e.g. 'AA:BB:CC:DD:EE:FF'
`lat_max`	No	Maximum latitude of bounding box
`lat_min`	No	Minimum latitude of bounding box
`long_max`	No	Maximum longitude of bounding box
`long_min`	No	Minimum longitude of bounding box
`name_like`	No	SQL LIKE pattern for device name, e.g. 'Galaxy%'
`search_after`	No	Pagination cursor from a previous response's 'search_after' field
`results_per_page`	No	Max results to return (1-100)

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.7/5.0

Behavior3/5

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

Annotations indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false, which are consistent with a read-only search. The description does not add behavioral details beyond what annotations provide, such as pagination behavior, result limits, or rate limits. It does not contradict annotations.

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

Conciseness5/5

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

The description is a single sentence that is concise and front-loaded. Every word adds value, with no redundancy or unnecessary details. It efficiently conveys the core purpose.

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

Completeness3/5

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

Given 9 parameters including pagination ('search_after') and bounding box, the description omits crucial context like pagination mechanics (cursor use) and that results are limited per page. While the output schema may document the response, the description should hint at pagination for proper agent invocation.

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 coverage is 100%, with each parameter having a description. The description groups parameters by type (name, MAC, location) but does not add significant meaning beyond what the schema already provides. For example, it does not explain the SQL LIKE pattern syntax for 'name_like' that is already in the schema.

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?

The description clearly states the tool searches WiGLE's Bluetooth/BLE database by name, MAC, or location. It uses a specific verb ('Search') and resource ('WiGLE's database of observed Bluetooth/BLE devices'), and the criteria are listed. This distinguishes it from sibling tools like bluetooth_detail (which likely retrieves details for a single device) and other type-specific searches.

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

Usage Guidelines3/5

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

The description implies usage for Bluetooth/BLE searches but does not explicitly state when to use this tool versus alternatives. It lacks guidance on when not to use it or preferred scenarios. Sibling tools are mentioned in context but not referenced in the description.

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

cell_detailA

Read-onlyIdempotent

Look up everything WiGLE knows about a single cell tower by its ID, including operator/network type and recorded sighting locations.

ParametersJSON Schema

Name	Required	Description	Default
`netid`	Yes	Cell tower identifier to look up, e.g. '310-410-12345-6789'

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already indicate read-only, idempotent, non-destructive behavior. Description adds that it returns 'everything WiGLE knows' including operator/network and sighting locations, providing more context without contradicting annotations.

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

Conciseness5/5

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

Single sentence, no redundant words, and effectively communicates the tool's purpose and scope.

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

Completeness5/5

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

Given low complexity (1 parameter, output schema present, rich annotations), the description is sufficiently complete. It covers the tool's function and return information without needing extra details.

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 coverage is 100% and includes an example for netid. The description contextualizes 'by its ID' but does not add further semantics beyond what the schema already provides, resulting in a baseline score.

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?

Description uses specific verb 'look up' and resource 'cell tower by its ID', clearly distinguishing from sibling searches (e.g., cell_search, network_detail). It explains what information is returned (operator/network type, sighting locations).

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

Usage Guidelines4/5

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

Context implies usage when a specific cell tower ID is known, and sibling names suggest alternatives, but no explicit when-to-use or when-not-to-use guidance is provided.

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

cell_searchA

Read-onlyIdempotent

Search WiGLE's database of observed cell towers by ID, operator, network type, or location.

ParametersJSON Schema

Name	Required	Description
`netid`	No	Cell tower identifier to match, e.g. '310-410-12345-6789'
`lat_max`	No	Maximum latitude of bounding box
`lat_min`	No	Minimum latitude of bounding box
`long_max`	No	Maximum longitude of bounding box
`long_min`	No	Minimum longitude of bounding box
`operator`	No	Carrier/operator name to match
`network_type`	No	Network type filter, e.g. 'GSM', 'UMTS', 'LTE', 'CDMA'
`search_after`	No	Pagination cursor from a previous response's 'search_after' field
`results_per_page`	No	Max results to return (1-100)

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.8/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the agent knows it's a safe read operation. The description adds no extra behavioral context beyond what annotations provide.

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

Conciseness5/5

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

A single, well-structured sentence that is front-loaded with the action and resource. Every word earns its place.

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?

Given 9 optional parameters, full schema descriptions, an output schema, and clear annotations, the description is nearly complete. It could mention bounding box constraints or pagination, but these are covered in the schema.

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 each parameter has a clear description in the schema. The tool description adds no additional meaning beyond that.

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?

The description clearly states 'Search WiGLE's database of observed cell towers by ID, operator, network type, or location.' It uses a specific verb ('Search') and resource, and distinguishes from sibling tools like bluetooth_search and network_search.

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

Usage Guidelines3/5

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

The description implies usage for searching cell towers but provides no explicit when-to-use or when-not-to-use guidance, nor mentions alternatives like network_search for Wi-Fi.

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

network_detailA

Read-onlyIdempotent

Look up everything WiGLE knows about a single network by its BSSID, including SSID history, encryption, and recorded sighting locations.

ParametersJSON Schema

Name	Required	Description	Default
`bssid`	Yes	MAC address / BSSID to look up, e.g. 'AA:BB:CC:DD:EE:FF'

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds behavioral context by specifying what data is returned (SSID history, encryption, locations), which is beyond the annotations. No contradictions.

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

Conciseness5/5

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

The description is a single sentence that efficiently conveys all necessary information with no redundant or vague words.

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

Completeness5/5

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

Given the presence of an output schema (context signal), the description need not detail return values. It sufficiently covers the purpose, inputs, and key outputs (SSID history, encryption, locations). Annotations cover safety and idempotency.

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?

The only parameter bssid is fully described in the schema (100% coverage), so the description adds no additional meaning beyond confirming its use. Baseline score of 3 applies.

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?

The description uses a specific verb 'Look up' and explicitly states the resource 'single network by its BSSID', listing included data (SSID history, encryption, locations). It clearly distinguishes from sibling tools like network_search (which searches) and bluetooth_detail/cell_detail (different network types).

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

Usage Guidelines3/5

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

The description implies usage for retrieving detailed information about a known network by BSSID, but lacks explicit guidance on when to prefer this tool over alternatives (e.g., network_search for queries, bluetooth_detail for Bluetooth). No 'when not to use' or prerequisite conditions are stated.

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

network_searchA

Read-onlyIdempotent

Search WiGLE's database of observed WiFi networks by SSID, BSSID, location, or encryption.

ParametersJSON Schema

Name	Required	Description
`city`	No	City name
`ssid`	No	Exact SSID to match
`bssid`	No	MAC address / BSSID to match, e.g. 'AA:BB:CC:DD:EE:FF'
`region`	No	State/region name
`country`	No	Two-letter country code, e.g. 'US'
`lat_max`	No	Maximum latitude of bounding box
`lat_min`	No	Minimum latitude of bounding box
`long_max`	No	Maximum longitude of bounding box
`long_min`	No	Minimum longitude of bounding box
`only_open`	No	If true, only return networks with no encryption
`ssid_like`	No	SQL LIKE pattern for SSID, e.g. 'Pretty Fly%'
`encryption`	No	Encryption filter, e.g. 'wpa', 'wpa2', 'wep', 'none'
`search_after`	No	Pagination cursor from a previous response's 'search_after' field
`results_per_page`	No	Max results to return (1-100)

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, establishing safety and idempotency. The description adds 'Search WiGLE's database', reinforcing a read-only operation. No contradictions, and the description provides minimal but sufficient behavioral context on top of annotations.

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

Conciseness5/5

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

A single sentence that front-loads the main action and scope. No redundant words or unnecessary details. Every part of the description earns its place.

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?

Given the tool has 14 optional parameters and an output schema exists, the description adequately covers the tool's purpose. It does not explain pagination or the 'search_after' parameter, but these are documented in the schema. The description is complete enough for an agent to understand core functionality.

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 each parameter is already documented. The tool description summarizes the parameter categories (SSID, BSSID, location, encryption) but adds no new semantic detail beyond what the schema provides. Baseline score of 3 is appropriate.

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?

The description clearly states it searches WiGLE's database of WiFi networks by multiple criteria (SSID, BSSID, location, or encryption). The tool name 'network_search' and the description distinguish it from sibling tools like 'bluetooth_search' and 'network_detail', which focus on different network types or individual records.

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

Usage Guidelines3/5

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

No explicit guidance on when to use this tool versus alternatives. While the name and description imply WiFi network search, and siblings suggest alternatives for other network types, the description does not state when to prefer this over more specific tools like 'network_detail' or when to use pagination parameters.

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

site_statsA

Read-onlyIdempotent

Get WiGLE-wide statistics: total WiFi/cell/Bluetooth networks and locations recorded, total users, and recent daily/monthly upload totals.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, not destructive; description adds specificity on returned statistics, providing value beyond annotations.

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

Conciseness5/5

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

Single, clear sentence that front-loads the action and lists outputs efficiently, with no fluff.

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

Completeness5/5

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

Output schema exists (not shown), so description need not detail return format; it covers all relevant statistic categories, and annotations are sufficient for a read-only tool.

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

Parameters4/5

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

No parameters exist (schema coverage 100%), so description need not add param info; adequate baseline given no params.

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?

Description clearly states 'Get WiGLE-wide statistics' and lists specific metrics (WiFi/cell/Bluetooth networks, locations, users, upload totals), distinguishing from sibling tools like user_stats (per-user) and search tools.

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

Usage Guidelines3/5

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

Implying use for aggregate stats, but no explicit when-to-use or when-not-to-use compared to siblings; context from sibling names partially clarifies.

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

user_statsA

Read-onlyIdempotent

Get WiGLE account statistics for the configured API user: rank, monthly rank, and counts of discovered WiFi/cell networks.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds context by naming the returned fields (rank, monthly rank, counts) and specifying the scope ('configured API user'), which goes beyond annotations.

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

Conciseness5/5

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

The description is a single, well-structured sentence that conveys the tool's purpose and output without any unnecessary words. It is front-loaded with the action verb 'Get'.

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?

Given no input parameters and an existing output schema, the description provides sufficient context. It mentions the user scope and key output fields, though it could briefly note that authentication is required (implied by 'configured API user').

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

Parameters4/5

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

There are no parameters, so schema coverage is 100%. The description does not need to add parameter details, and it appropriately focuses on the output.

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?

The description clearly states the tool retrieves WiGLE account statistics for the configured API user, specifying the exact data (rank, monthly rank, counts). It distinguishes from sibling tools like network_search or bluetooth_detail by focusing on user-level statistics.

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

Usage Guidelines3/5

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

The description implies the tool is for querying account-level stats, but does not explicitly state when to prefer it over site_stats or other tools. No when-not-to-use or alternative recommendations are provided.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

8 tool updatesv0.1.0Jun 27, 2026
- First observedbluetooth_detail
- First observedbluetooth_search
- First observedcell_detail
- First observedcell_search
- First observednetwork_detail
- First observednetwork_search
- First observedsite_stats
- First observeduser_stats

Deploy Server

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

TDQS

A4.2/5.0

Scored 2026-06-27 18:20 across 8 tools

Disambiguation5/5

Each tool targets a distinct domain (Bluetooth, cell, WiFi, stats) with clear search/detail pairs. No overlapping purposes.

Naming Consistency5/5

All tools follow a consistent domain_action pattern (e.g., bluetooth_detail, network_search). No mixing of conventions.

Tool Count5/5

8 tools is well-scoped for querying three data types plus stats. Each tool earns its place, neither too few nor too many.

Completeness5/5

For a read-only database query service, the surface covers search and detail for each data type, plus site and user stats. No obvious gaps.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

mcp A
ai.llmse
Public MCP server for the LLM Search Engine
Search RAG Systems Developer Tools
102
UnifAPIOAuth
com.unifapi
Hosted MCP server for live public-data APIs and Skills for AI agents.
Open Data Search AI & Machine Learning
2
H-Index A
ai.xr-utilities
Capability registry for the agentic economy. Semantic search over verified MCP server listings.
Search Documentation Access
2
mcp AOAuth
io.scorecard
MCP server providing access to the Scorecard API to evaluate and optimize LLM systems.
RAG Systems Monitoring Testing & QA Tools
3

Related MCP Servers

LLM Researcher
Browser Automation Web Scraping
Code-Hex
F
license
Not graded
quality
D
maintenance
A lightweight MCP server that enables LLMs to search the web via DuckDuckGo, search GitHub code repositories, and extract clean content from web pages in LLM-friendly formats.
Updated a year ago (2025-06-16 14:49 UTC)
8
-
pumperly-mcp
Travel & Transportation Location Services Search
GeiserX
A
license
A
quality
A
maintenance
MCP server that exposes any Pumperly instance to LLMs, enabling real-time fuel price queries, station search, route planning, and geocoding.
Updated 18 days ago (2026-09-02 21:46 UTC)
5
48 npm
3
GPL 3.0
Local-MCP-server
Browser Automation Web Scraping
BigStationW
F
license
Not graded
quality
D
maintenance
Enables tool-calling LLMs to search the internet, capture website images, extract webpage text, and more via a local MCP server.
Updated 5 months ago (2026-04-27 12:33 UTC)
15
-
aprs-mcp
Communication Location Services
gflerm
A
license
A
quality
C
maintenance
MCP server that exposes APRS-IS network tools to LLM agents, enabling sending APRS messages, querying positions, finding nearby stations, and listening to live packet streams.
Updated a month ago (2026-08-08 15:22 UTC)
5
MIT