EdgeDefense
Server Details
Scan your home network and local machine for security risks, open ports, weak Wi-Fi, unknown devices. Providing with a trust score and clear explanations.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.8/5 across 11 of 11 tools scored.
Each tool has a clearly distinct purpose, covering different aspects of network scanning, device details, explanations, performance metrics, and change detection. Even the three performance tools (latency_check, network_stats, speed_test) are well-differentiated by their focus on ping/DNS, adapter stats, and internet throughput respectively.
All tools are prefixed with 'edgedefense_' and mostly follow a verb_noun pattern (e.g., scan_network, list_devices). However, a few exceptions like 'local_security' (adjective_noun) and 'whats_changed' (phrase) break the pattern slightly, though they are still understandable.
With 11 tools, the server covers the essential operations for local network monitoring without being overly bloated. Each tool serves a specific need, and the count is well within the ideal range for this domain.
The toolset covers the full lifecycle: scan, list, detail, explain, trust score, performance checks, local security, naming, and change detection. Minor gaps like scheduling scans or export functionality exist, but the core capabilities are thorough for a home network tool.
Available Tools
11 toolsedgedefense_explain_findingARead-onlyIdempotentInspect
Explain what a flagged issue means, why it matters, and what to do.
Every explanation also states what the check genuinely cannot determine --
for example, that detecting an open Telnet port does not prove the password
is still the factory default.
Args:
finding_id (str): the id from a previous response.
response_format (ResponseFormat): 'markdown' or 'json'. Default 'markdown'.
Returns:
str: In markdown mode: severity, the affected device, what the finding
means, what to do about it, and the limits of the check.
In json mode:
{
"finding": { ... }, # same finding schema as scan_network
"device": { ... } | null # the affected device, if any
}
Examples:
- Use when: "Why is that a problem?" after a scan flagged something
- Use when: "Explain telnet_exposed:a4:cf:12:34:56:78"
- Don't use when: the user wants the device overview - use
edgedefense_get_device_detail
Error Handling:
If the id does not match, returns the list of currently available
finding ids so the right one can be selected immediately.
| Name | Required | Description | Default |
|---|---|---|---|
| finding_id | Yes | The finding_id from a previous response, e.g. 'telnet_exposed:a4:cf:12:34:56:78'. Every scan response includes these | |
| response_format | No | 'markdown' for readable prose, 'json' for structured data | markdown |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, idempotentHint, destructiveHint), description adds that it states limitations of the check and error handling returns list of available IDs if not found.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-organized with sections (description, args, returns, examples, error handling). Every sentence adds value, no wasted words, front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Comprehensive: describes both return formats, error handling, and includes examples. Distinguishes from sibling tools. Output schema exists so return values need not be explained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds context: example for finding_id, default for response_format, and description of return modes, improving usability.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool explains what a flagged issue means, why it matters, and what to do. It uses a specific verb and resource and distinguishes from sibling edgedefense_get_device_detail.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit when-to-use examples (after scan, when user asks why it's a problem) and a don't-use case (for device overview) with alternative tool named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
edgedefense_get_device_detailARead-onlyIdempotentInspect
Show everything known about a single device.
Covers device type and how confident that guess is, manufacturer, hostname,
open ports with what each one does, advertised services, when it was first
seen on this network, and any findings against it.
Args:
device_id (str): device_id, IP address, MAC address, or hostname.
response_format (ResponseFormat): 'markdown' or 'json'. Default 'markdown'.
Returns:
str: In markdown mode, a full profile of the device.
In json mode:
{
"device": { ... }, # same device schema as scan_network
"findings": [ ... ] # findings referencing this device
}
Examples:
- Use when: "What is 192.168.1.40?" -> device_id='192.168.1.40'
- Use when: "Tell me about that unknown device" -> pass its device_id
- Don't use when: the user wants an overview - use edgedefense_list_devices
Error Handling:
If the identifier does not match, returns a message listing the
addresses that are available, so the correct one can be chosen without
another round trip.
| Name | Required | Description | Default |
|---|---|---|---|
| device_id | Yes | Which device to look up. Accepts the device_id from a previous response (e.g. 'a4:cf:12:34:56:78' or 'ip-192.168.1.40'), a plain IP address (e.g. '192.168.1.40'), a MAC address, or the device's hostname | |
| response_format | No | 'markdown' for readable prose, 'json' for structured data | markdown |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds concrete behavioral details beyond the annotations, including how the tool handles invalid identifiers (returns a list of available addresses) and the exact return structure in json mode. The annotations already declare it as read-only and idempotent, and the description is consistent with 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections for args, returns, examples, and error handling. It is comprehensive but not overly long, with each section adding distinct value. The first sentence efficiently summarizes the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity, the description is complete. It covers all relevant aspects: what the tool does, parameter details, return formats, example usage, and error handling. Since no output schema exists in the input (only described in text), the description provides sufficient detail about return structures.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already has 100% coverage, so the baseline is 3. The description adds value by explaining what types of identifiers the device_id parameter accepts (device_id, IP, MAC, hostname) and the default value and purpose of response_format, going beyond the schema's brief descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it shows everything known about a single device and lists the specific attributes covered (device type, manufacturer, hostname, open ports, etc.). It also distinguishes from the sibling edgefense_list_devices by providing a clear 'don't use' example.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage examples for when to use the tool, such as 'What is 192.168.1.40?', and explicitly says not to use it when the user wants an overview, directing to the sibling tool edgefense_list_devices. Error handling guidance is also included.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
edgedefense_get_trust_scoreARead-onlyInspect
Compute the 0-100 network trust score with the reasons behind it.
The score starts at 100 and subtracts points for exposed risky services,
unidentified devices, and unusually broad attack surface. Each category is
capped so no single issue dominates. Every deduction traces to a finding
the user can read.
The scoring is deliberately calibrated so that an ordinary, well-configured
home network scores in the 90s. A low score means something real.
Args:
response_format (ResponseFormat): 'markdown' or 'json'. Default 'markdown'.
Returns:
str: In markdown mode, a short screenshot-friendly card: the headline
number and grade, two to three plain-language reasons, and the per-
category point breakdown.
In json mode:
{
"score": int, # 0-100
"grade": str, # "Strong"|"Good"|"Fair"|"Needs attention"|"At risk"
"reasons": [str],
"deductions": {str: int}, # category label -> points subtracted
"device_count": int
}
Examples:
- Use when: "What's my network trust score?" -> defaults
- Use when: "How secure is my network out of 100?" -> defaults
- Don't use when: the user wants the detail behind one issue - use
edgedefense_explain_finding
Error Handling:
Returns a message directing the user to scan first if no scan has run.
If a scan found no devices at all, reports that explicitly rather than
returning a perfect score for an empty result.
| Name | Required | Description | Default |
|---|---|---|---|
| response_format | No | 'markdown' for readable prose, 'json' for structured data | markdown |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint=true annotation, the description details the scoring mechanism: starts at 100, subtracts for risky services, capped categories, deductions traceable to findings. It also explains calibration for home networks and that low scores indicate real issues. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections (main description, Args, Returns, Examples, Error Handling). The core purpose is front-loaded. Every sentence adds value without redundancy. It is appropriately detailed without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter), the description covers all necessary aspects: purpose, usage, parameters, return formats, error handling, and edge cases. The output schema is described in detail, and examples are provided. No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter response_format is already well-described in the schema. The description adds context by saying 'markdown for readable prose, json for structured data' and describing the return structure for each format, which provides additional clarity beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it computes the 0-100 network trust score with reasons. It distinguishes from sibling tools by specifying when to use edgedefense_explain_finding instead. The verb 'compute' and resource 'network trust score' are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit usage examples are provided: 'Use when: What's my network trust score?' and 'Don't use when: the user wants the detail behind one issue - use edgedefense_explain_finding'. Error handling for missing scans and empty results is also described, giving clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
edgedefense_latency_checkARead-onlyInspect
Measure the round trip to your router, and how fast names resolve.
Reports minimum, average and maximum round-trip time to the default
gateway, jitter between consecutive packets, and packet loss. With DNS
included, it times a lookup against each configured resolver.
These two numbers separate the two common causes of "everything feels
slow". High latency to your own router is a local wireless problem. Fast
router latency with slow DNS is a resolver problem, and shows up as a pause
before every new site loads while everything already open stays fast.
Packets go only to your own gateway and to the DNS servers this machine
already uses. No third-party service is contacted.
Args:
count (int): pings to send to the gateway. Default 5.
include_dns (bool): also time DNS lookups. Default True.
response_format (ResponseFormat): 'markdown' or 'json'. Default 'markdown'.
Returns:
str: In markdown mode, the round-trip figures, per-resolver timings, and
a short plain-language reading of what those numbers imply.
In json mode:
{
"gateway": {
"host": str,
"sent": int,
"received": int,
"loss_percent": float | null,
"min_ms": float | null,
"avg_ms": float | null,
"max_ms": float | null,
"jitter_ms": float | null,
"samples_ms": [float],
"error": str | null
} | null,
"dns": [
{
"server": str,
"query": str,
"avg_ms": float | null,
"min_ms": float | null,
"max_ms": float | null,
"failures": int,
"error": str | null
}
],
"verdict": [str],
"warnings": [str]
}
Examples:
- Use when: "Why do my video calls keep stuttering?" -> count=10
- Use when: "Is my DNS slow?" -> defaults
- Use when: "Is the problem my Wi-Fi or my ISP?" -> defaults, then read
the gateway figures
- Don't use when: the user wants throughput in Mbps - use
edgedefense_speed_test
Error Handling:
Never raises. Many routers are configured not to answer pings; that is
reported as an inconclusive result rather than as a fault, because it
genuinely is not one.
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | How many pings to send to the router. More is steadier | |
| include_dns | No | Also time a name lookup against each DNS server this machine is configured to use | |
| response_format | No | 'markdown' for readable prose, 'json' for structured data | markdown |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, destructiveHint=false, idempotentHint=false. The description adds significant context: it never raises errors, handles non-responsive routers as inconclusive, and states no third-party services are contacted. This covers safety and edge cases 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (Args, Returns, Examples, Error Handling). Every sentence adds value; no redundancy. Information is front-loaded with purpose and key differentiators.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3 optional params, output schema exists), the description fully covers inputs, outputs in both formats, error behavior, and interpretation guidance. The output schema details are already available, so the description complements rather than duplicates.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds meaning: 'count' default 5 with 'more is steadier', 'include_dns' timing against configured resolvers, and response_format outcome. While schema descriptions are present, the tool description enriches them with practical context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool measures round-trip time to the default gateway and DNS resolution time, distinguishing it from sibling tools like edgedefense_speed_test. It uses specific verbs ('measure', 'reports') and identifies the resources (router, DNS servers).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use examples ('video calls stuttering', 'is my DNS slow?') and a clear when-not-to-use case (throughput → use speed_test). It also explains how to interpret results for diagnosing Wi-Fi vs ISP issues.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
edgedefense_list_devicesARead-onlyIdempotentInspect
List devices found by the most recent scan, optionally filtered.
Reads cached results and does not re-scan, so it is fast and repeatable.
Args:
filter_type (DeviceFilter): 'all', 'unknown', or 'flagged'. Default 'all'.
response_format (ResponseFormat): 'markdown' or 'json'. Default 'markdown'.
Returns:
str: In markdown mode, a numbered list with each device's name, type,
address, manufacturer and open-port count.
In json mode:
{
"filter": str, # the filter applied
"total_devices": int, # total discovered, before filtering
"count": int, # devices in this response
"devices": [ ... ] # same device schema as scan_network
}
Examples:
- Use when: "List everything on my network" -> filter_type='all'
- Use when: "Which devices couldn't you identify?" -> filter_type='unknown'
- Use when: "What has problems?" -> filter_type='flagged'
- Don't use when: no scan has run yet - call edgedefense_scan_network first
Error Handling:
Returns a message directing the user to run a scan if none has been run.
| Name | Required | Description | Default |
|---|---|---|---|
| filter_type | No | 'all' for every device, 'unknown' for devices that could not be identified, 'flagged' for devices with at least one finding against them | all |
| response_format | No | 'markdown' for readable prose, 'json' for structured data | markdown |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds context that it reads cached results and does not re-scan, and includes error handling for no scan run. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (summary, behavior, Args, Returns, Examples, Error Handling). Every sentence provides essential information without repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only 2 non-required parameters, the description fully covers usage, parameters, return values (both markdown and json), and error handling. The output schema further enhances completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds significant value by explaining each parameter option in plain language and detailing the return format, including structure of JSON response.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List devices found by the most recent scan, optionally filtered.' It identifies the specific verb and resource, and distinguishes from sibling tools like scanning, getting details, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes explicit usage guidance: it is fast and repeatable because it reads cached results, and provides examples of when to use each filter type. It also warns not to use if no scan has run, directing to call edgedefense_scan_network first.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
edgedefense_local_securityARead-onlyIdempotentInspect
Run security and configuration checks on the computer running the scan.
Checks Wi-Fi encryption (warns if connected to an open network), DNS configuration,
and lists local ports that are exposed to the network (listening on 0.0.0.0).
Args:
response_format (ResponseFormat): 'markdown' or 'json'. Default 'markdown'.
Returns:
str: In markdown mode, a formatted report of the local security posture.
In json mode:
{
"wifi_secure": bool | null,
"wifi_ssid": str | null,
"wifi_auth_type": str | null,
"dns_servers": [ ... ],
"listening_ports": [ {"protocol": str, "port": int, "address": str} ],
"warnings": [ ... ]
}
| Name | Required | Description | Default |
|---|---|---|---|
| response_format | No | 'markdown' for readable prose, 'json' for structured data | markdown |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate read-only, idempotent, non-destructive behavior. Description adds significant value by detailing the specific checks performed (Wi-Fi encryption, DNS, listening ports) and the return format, 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise and well-structured: initial sentence summarizing purpose, bullet-like list of checks, followed by clear Args and Returns sections. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a single parameter and an output schema, the description fully explains the tool's functionality, parameter options, and return structure, leaving no gaps for an agent to misinterpret.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter (response_format) with full schema coverage. Description elaborates on the parameter's purpose (choosing output format) and default value, adding clarity beyond the schema's description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool runs security and configuration checks on the local machine, listing specific checks (Wi-Fi encryption, DNS, listening ports). This distinguishes it from sibling tools like edgedefense_scan_network and edgedefense_network_stats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description explains what the tool checks and its output, providing context for when to use it. However, it does not explicitly state when not to use it or mention alternative tools, though sibling names imply differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
edgedefense_name_deviceAIdempotentInspect
Assign a persistent friendly name to a device.
This name will be saved locally and applied to the device in all future scans.
It helps turn unidentified devices into a network you understand. This is a
write operation.
Args:
device_id (str): The device identifier (device_id, IP, MAC).
label (str): The name to assign.
Returns:
str: Confirmation message.
| Name | Required | Description | Default |
|---|---|---|---|
| label | Yes | The friendly name to assign to the device (e.g. 'SimpliSafe base station'). | |
| device_id | Yes | Which device to name. Accepts the device_id from a previous response, or a plain IP or MAC address. |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds beyond annotations: states it's a write operation, the name is saved locally and persists across scans, and returns a confirmation message. Annotations indicate readOnlyHint=false and idempotentHint=true, consistent with a safe, idempotent write.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Compact and well-structured: purpose, explanation, then args/returns. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given output schema exists and 100% parameter coverage, description covers core behavior and return type. Lacks error handling or permissions, but sufficient for this simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%. Description adds that device_id accepts ID, IP, or MAC (not stated in schema), and gives an example for label. Extra value but not extensive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb+resource: 'Assign a persistent friendly name to a device.' Distinct from siblings like 'edgedefense_list_devices' or 'edgedefense_get_device_detail'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides context: 'It helps turn unidentified devices into a network you understand.' Notes it's a write operation, but doesn't explicitly state when not to use or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
edgedefense_network_statsARead-onlyInspect
Report how each network adapter is performing right now.
Covers current upload and download throughput per adapter, cumulative
traffic, link speed, MTU, and packet error and drop rates. With Wi-Fi
included, it also reports signal strength in dBm, the band and channel in
use, the negotiated radio rate, and how many neighbouring networks are
competing for the same channel.
This is the right first stop for "my internet is slow", because it
distinguishes a weak or crowded Wi-Fi link from an actual problem with the
internet connection. Those have completely different fixes, and a speed
test alone cannot tell them apart.
Everything here is read from counters the operating system already keeps.
Nothing is transmitted.
Args:
sample_seconds (float): seconds to watch traffic for the live rate.
Default 2.0.
include_wifi (bool): include Wi-Fi link quality and channel congestion.
Default True.
response_format (ResponseFormat): 'markdown' or 'json'. Default 'markdown'.
Returns:
str: In markdown mode, a report of each active adapter's current and
cumulative traffic and error rate, followed by the Wi-Fi link and any
specific, measured advice about it.
In json mode:
{
"interfaces": {
"sample_seconds": float,
"interfaces": [
{
"name": str,
"description": str | null,
"is_up": bool,
"mac": str | null,
"mtu": int | null,
"link_speed_mbps": float | null,
"bytes_sent": int | null,
"bytes_recv": int | null,
"packets_sent": int | null,
"packets_recv": int | null,
"errors_in": int | null,
"errors_out": int | null,
"drops_in": int | null,
"drops_out": int | null,
"error_rate": float | null, # 0.0-1.0, null if unknown
"is_virtual": bool,
"send_rate_bps": float | null,
"recv_rate_bps": float | null
}
],
"warnings": [str]
},
"wifi": {
"link": {
"ssid": str | null,
"bssid": str | null,
"band": str | null, # "2.4 GHz" | "5 GHz" | "6 GHz"
"channel": int | null,
"signal_percent": int | null,
"signal_dbm": float | null,
"signal_quality": str | null, # "excellent".."very weak"
"rx_rate_mbps": float | null,
"tx_rate_mbps": float | null,
"radio_type": str | null,
"authentication": str | null
} | null,
"nearby_count": int,
"nearby": [ {"ssid": str, "channel": int, "band": str, "signal_percent": int} ],
"channel_usage": [ {"channel": int, "networks": int} ],
"same_channel_networks": int | null,
"advice": [str],
"warnings": [str]
} | null
}
Examples:
- Use when: "Why is my network slow?" -> defaults
- Use when: "How strong is my Wi-Fi signal?" -> defaults
- Use when: "What's using my bandwidth right now?" -> sample_seconds=5
- Don't use when: the user wants a speed in Mbps against the internet -
use edgedefense_speed_test
Error Handling:
Never raises for network conditions. A machine on Ethernet reports no
Wi-Fi link, which is a normal result rather than an error. Platforms
that do not expose a given counter report null for it rather than zero,
so a missing counter is never mistaken for a healthy one.
| Name | Required | Description | Default |
|---|---|---|---|
| include_wifi | No | Also report Wi-Fi signal strength, band, channel and how many nearby networks share that channel. Adds a few seconds | |
| sample_seconds | No | How long to watch traffic to compute the live throughput rate. 2 seconds is a good default; longer is steadier but slower | |
| response_format | No | 'markdown' for readable prose, 'json' for structured data | markdown |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark readOnlyHint as true, and the description reinforces that it only reads OS counters without transmitting anything. It also explains error handling: no errors for normal conditions like missing Wi-Fi, missing counters return null. This adds behavioral context beyond what annotations alone provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections: purpose, detailed metric list, usage guidance, args, returns, examples, error handling. It is front-loaded with the most important information and every sentence adds value. No redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and the presence of a detailed output schema, the description is fully complete. It covers input parameters, output structure (both markdown and json), use cases, error handling, and behavioral guarantees. Nothing is left unclear for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters have schema descriptions covering 100%. The description adds meaning by explaining the purpose of sample_seconds (watch traffic for live rate), include_wifi (include Wi-Fi quality), and response_format (markdown or json), with examples showing how to use them. This adds significant value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a clear verb 'Report how each network adapter is performing right now' and enumerates specific metrics. It distinguishes the tool from sibling tools like edgedefense_speed_test by stating it is the right first stop for 'my internet is slow' and that it tells apart Wi-Fi issues from internet connection problems.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use it ('my internet is slow', Wi-Fi signal, bandwidth usage) and when not to use it (for internet speed test, pointing to edgedefense_speed_test). It provides specific examples with sample parameter changes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
edgedefense_scan_networkARead-onlyInspect
Discover every device on the local network and summarise what is there.
This is the entry point: the other tools read the results of the most recent
scan, so call this first. Discovery uses the system address table, device
self-announcements (mDNS), and a check of common ports. It requires no
elevated privileges and makes no outbound internet requests.
Args:
scan_depth (ScanDepth): 'quick' (~10s) or 'full' (~30s). Default 'quick'.
response_format (ResponseFormat): 'markdown' or 'json'. Default 'markdown'.
Returns:
str: In markdown mode, a readable summary: device count, a breakdown by
device type, the trust score with reasons, notable findings, and the
full device list.
In json mode, an object with this schema:
{
"started_at": str, # ISO-8601 UTC
"finished_at": str,
"scan_depth": str, # "quick" | "full"
"subnet": str | null, # e.g. "192.168.1.0/24"
"devices": [
{
"device_id": str, # MAC, or "ip-<address>" if no MAC
"ip": str,
"mac": str | null,
"hostname": str | null,
"vendor": str | null,
"device_type": str, # e.g. "router", "phone_or_tablet"
"type_confidence": str, # "high"|"medium"|"low"|"none"
"open_ports": [int],
"services": {str: str}, # port -> service description
"mdns_services": [str],
"randomised_mac": bool,
"is_gateway": bool,
"is_self": bool,
"sources": [str], # "arp" | "mdns" | "self"
"first_seen": str | null,
"last_seen": str | null,
"label": str
}
],
"findings": [
{
"finding_id": str, # stable; pass to explain_finding
"code": str,
"severity": str, # "high"|"medium"|"low"|"info"
"title": str,
"summary": str,
"detail": str,
"what_to_do": str,
"limitations": str,
"device_id": str | null,
"evidence": object
}
],
"warnings": [str],
"trust_score": {"score": int, "grade": str, "reasons": [str], ...}
}
Examples:
- Use when: "What's on my network?" -> defaults
- Use when: "Do a thorough scan" -> scan_depth='full'
- Don't use when: results already exist and the user is asking a
follow-up question - use edgedefense_list_devices or
edgedefense_get_device_detail instead, which do not re-scan
Error Handling:
Never raises for network conditions. If discovery is partially blocked
(VPN active, mDNS port unavailable), the scan still returns whatever was
found and explains the gap under "Notes" / "warnings".
| Name | Required | Description | Default |
|---|---|---|---|
| scan_depth | No | 'quick' (default, ~10 seconds, checks 12 common ports) or 'full' (~30 seconds, checks 42 ports and listens longer for device announcements) | quick |
| response_format | No | 'markdown' for readable prose, 'json' for structured data | markdown |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses scan techniques (system address table, mDNS, common ports), privileges (none required), network behavior (no outbound requests), and error handling (never raises, returns partial results with warnings). Annotations already indicate read-only and non-destructive, so no contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Efficiently structured with clear sections (Args, Returns, Examples, Error Handling). Front-loaded with purpose and usage. No unnecessary sentences; every part adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 optional params, output schema provided), the description is exceptionally complete. It covers scan depth choices, output formats, error behavior, and its role among siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with well-described enums. The description adds meaningful extra detail: quick (~10s) vs full (~30s) and the effect on port scanning, as well as default values. This enhances understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Discover every device on the local network and summarise what is there.' It also distinguishes itself as the entry point tool, contrasting with sibling tools that read previous scan results.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: call this first, use with default or full scan depth, and when not to use (if results already exist, use edgedefense_list_devices or edgedefense_get_device_detail instead). Includes example user queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
edgedefense_speed_testARead-onlyInspect
Measure real download and upload speed, latency, and bufferbloat.
**This is the only tool in EdgeDefense that contacts the internet.** Every
other tool reads local state or talks only to the user's own network. This
one has to transfer real data to and from Cloudflare's public speed test
service, because throughput cannot be measured any other way. It needs no
account or API key, and no identifying information is attached beyond what
any HTTPS request unavoidably reveals. The user's public IP address is
deliberately excluded from the result.
It transfers a meaningful amount of data - typically tens to hundreds of
megabytes - so it is worth avoiding on a metered or capped connection.
Alongside throughput it measures bufferbloat: how much latency rises while
the connection is saturated. That number, not the download figure, is
usually what explains a call breaking up when someone else starts a
download, and it is fixed in the router rather than by buying more speed.
Args:
duration (float): seconds per phase. Default 6.0.
include_upload (bool): measure upload too. Default True.
streams (int): parallel connections. Default 4.
response_format (ResponseFormat): 'markdown' or 'json'. Default 'markdown'.
Returns:
str: In markdown mode, the headline speeds, latency under load with a
bufferbloat grade, what the measured connection can realistically
support, and how the measurement was taken.
In json mode:
{
"download_mbps": float | null,
"upload_mbps": float | null,
"idle_latency_ms": float | null,
"jitter_ms": float | null,
"loaded_latency_ms": float | null,
"bufferbloat_ms": float | null,
"bufferbloat_grade": str | null, # "A+" .. "F"
"bytes_downloaded": int,
"bytes_uploaded": int,
"download_streams": int,
"upload_streams": int,
"server_location": str | null,
"server_colo": str | null,
"endpoint": str,
"duration_seconds": float | null,
"capability_notes": [str],
"warnings": [str]
}
Examples:
- Use when: "How fast is my internet?" -> defaults
- Use when: "Am I getting the speed I pay for?" -> defaults
- Use when: "Why do calls break up when someone downloads?" ->
defaults, then read bufferbloat_grade
- Don't use when: the user asked why the network feels slow without
asking for a number - edgedefense_network_stats and
edgedefense_latency_check diagnose that locally, in less time, and
without sending anything
Error Handling:
Never raises for network conditions. If the endpoint is unreachable the
result comes back with null speeds and an explanation in warnings,
rather than an exception. A phase that fails does not prevent the
others from being reported.
| Name | Required | Description | Default |
|---|---|---|---|
| streams | No | Parallel connections. A single connection cannot fill a fast link, so lowering this will under-report gigabit connections | |
| duration | No | Seconds to spend on each of the download and upload phases. 6 is enough for an accurate reading on most connections | |
| include_upload | No | Measure upload as well as download. Roughly doubles the runtime | |
| response_format | No | 'markdown' for readable prose, 'json' for structured data | markdown |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, openWorldHint), the description adds crucial behavioral details: it contacts the internet, transfers tens to hundreds of megabytes, avoids metered connections, measures bufferbloat, requires no account, excludes the public IP, and never raises for network conditions. This significantly enriches agent understanding.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (paragraphs, Args, Returns, Examples, Error Handling) and each sentence adds value. It is slightly lengthy but appropriately comprehensive, making it easy for an agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity, 100% schema coverage, presence of output schema, and zero required parameters, the description is fully complete. It covers behavior, return formats (markdown and JSON), error handling, usage examples, and sibling differentiation with minimal gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with good parameter descriptions. The description adds value by explaining default values' rationale (e.g., '6 is enough for an accurate reading on most connections') and behavioral implications (e.g., lowering streams under-reports gigabit connections). While schema already covers basic semantics, the description provides additional context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Measure real download and upload speed, latency, and bufferbloat.' It specifies the verb and resource, and distinguishes itself from siblings by noting it is the only tool that contacts the internet, while others read local state or talk only to the user's own network.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use examples (e.g., 'How fast is my internet?') and when-not-to-use alternatives (e.g., 'Don't use when the user asked why the network feels slow without asking for a number' with named alternatives edgedefense_network_stats and edgedefense_latency_check).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
edgedefense_whats_changedARead-onlyIdempotentInspect
Compare the most recent scan with the one before it to find changes.
Reports new devices that appeared, devices that vanished, and any ports that
opened or closed on devices that were present in both scans.
Args:
response_format (ResponseFormat): 'markdown' or 'json'. Default 'markdown'.
Returns:
str: In markdown mode, a formatted summary of all changes.
In json mode:
{
"current_finished_at": str,
"previous_finished_at": str,
"new_devices": [ ... ],
"vanished_devices": [ ... ],
"port_changes": [ ... ],
"has_changes": bool
}
Examples:
- Use when: "What changed since yesterday?"
- Use when: "Anything new on my network?"
| Name | Required | Description | Default |
|---|---|---|---|
| response_format | No | 'markdown' for readable prose, 'json' for structured data | markdown |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint, idempotentHint, and destructiveHint, and the description adds that it reports changes from the last two scans, including response format and JSON structure. No contradiction; adds meaningful behavioral context 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: core purpose first, then bullet points for changes, then Args/Returns sections, then usage examples. It is concise with no wasted words and front-loads the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity is low (one parameter, no required params, no nested objects) and it has an output schema in the description, the tool description covers input, output, behavior, and usage context completely. Sibling tool list shows this is the only delta/comparison tool, making it self-sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter (response_format) has a clear description in the schema and an enhanced description in the tool text ('markdown for readable prose, json for structured data'). Schema coverage is 100%, and the description adds value beyond the schema definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it compares the two most recent scans to find changes, listing specific change types (new devices, vanished devices, port changes). This is a specific verb+resource combination and distinguishes it from siblings like edgedefense_explain_finding or edgedefense_scan_network.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage examples ('What changed since yesterday?' and 'Anything new on my network?'), telling the agent when to invoke this tool. However, it does not explicitly mention when not to use it or contrast with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!