SentryFi Wi-Fi safety app (App Store, Google Play): who is on my Wi-Fi, public Wi-Fi risk.
Scored across 3 tools
The three tools split cleanly into public-network risk, device identification on one's own network, and home router hardening, and each description explicitly names when to use a sibling instead. The only real overlap is the phrase 'someone is using my wifi' / unknown devices, which appears in both identify_wifi_devices and secure_my_wifi, so an agent may hesitate between them for that one query.
All three are snake_case verb_phrase names (check_, identify_, secure_) with the domain word 'wifi' embedded, which is predictable and readable. 'secure_my_wifi' breaks the pure verb_noun shape with the possessive 'my', a minor deviation from the other two.
Three tools is on the thin side but map one-to-one onto the three sub-domains the server claims (public Wi-Fi, own-network devices, home router), with no filler or duplicated entries. Each tool earns its place rather than being a family of near-identical variants.
Within the deliberately non-scanning, advisory scope, the surface covers the main lifecycle: risk assessment for public networks, inventory/vendor lookup for the home network, and remediation for the home router. Gaps are minor — there is no way to look up a specific SSID reputation, assess password strength, or check known breach exposure, all of which agents may reasonably be asked about.
Use this when the user is about to join, or is on, hotel, airport, café (coffee shop), rental, campus or other public Wi-Fi and asks "is public wifi safe", "is hotel wifi safe", whether to do banking or work there, whether a sign-in page or a network name looks fake (evil twin / fake wifi), or what to watch out for. Also use it when they ask who can see their browsing on hotel or café Wi-Fi ("can the wifi owner see my history", "does incognito hide my browsing", "does a VPN protect me on public wifi"): the card shows what the Wi-Fi owner, hotel, other guests or a VPN provider can and cannot see, and how HTTPS, a VPN or encrypted DNS change that. Fill in what the user said; use "unknown" or null for anything they did not say rather than guessing. Returns a 0–100 score (100 = no warning signs) from their answers, the signals behind it, advice per activity, who can see what, and a checklist for that venue. Do not use for home Wi-Fi security or hack worries (use secure_my_wifi), for recommending VPN or security products, to monitor or read another person's activity, or for getting onto a network without permission. Does not scan or connect to any network; works only from what the user tells ChatGPT.
| Name | Required | Description | Default |
|---|---|---|---|
| venue | Yes | Where the Wi-Fi is. | |
| security | No | open = no password; shared_password = one password for everyone (e.g. on a card); private_password = only you have it; enterprise_login = personal username/password (e.g. eduroam). | unknown |
| usingVpn | No | ||
| httpsOnly | No | Only HTTPS sites (HTTPS-only mode on). | |
| activities | No | What the user wants to do on this network. | |
| signInAsks | No | What the sign-in page asks for. | |
| signInPage | No | Whether a sign-in (captive) page appeared and if its address started with https or http. | unknown |
| encryptedDns | No | Private DNS / DNS over HTTPS turned on. | |
| nameConfirmed | No | true if the exact network name was confirmed with staff or an official sign. | |
| certificateWarning | No | true if the device showed a certificate or "not private" warning. | |
| mobileDataAvailable | No | ||
| similarNetworkNames | No | true if several networks with similar names are visible. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare a safe, read-only, idempotent, closed-world operation, so the bar is lower, but the description still adds the crucial behavioral fact that it does not scan or connect to any network and works only from user-reported answers. It also describes what the returned card contains. It stops short of explaining scoring weights or confidence, which keeps it at 4 rather than 5.
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?
It is front-loaded with the use case, then the returned content, then the exclusions, and the quoted user phrasings make the trigger conditions concrete. The paragraph is long and dense with many quoted examples, which is slightly more than strictly needed, but each sentence contributes selection or behavioral 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?
For a 12-parameter tool with no output schema, the description covers the input contract (fill from user statements, unknown/null otherwise), the return payload (score, signals, per-activity advice, visibility, checklist), and the hard boundary (no scanning or connecting). Nothing an agent needs to select or call it correctly appears to be missing.
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?
With 83% schema coverage the schema already carries most parameter meaning, so the baseline is 3; the description earns an extra point by instructing the agent to fill in only what the user actually said and to use "unknown" or null instead of guessing, which is real guidance the schema does not encode. It does not explain individual fields beyond that.
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 names a specific analysis task (assessing public Wi-Fi risk from what the user reports) and states the concrete output: a 0–100 score, the signals behind it, per-activity advice, a who-can-see-what breakdown and a venue checklist. It also distinguishes itself from the sibling secure_my_wifi by excluding home Wi-Fi and hack worries.
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?
It gives explicit trigger phrasings ("is hotel wifi safe", "does incognito hide my browsing"), lists the situations that select this tool (about to join or already on hotel/airport/café/campus Wi-Fi), and names exclusions with routing: home Wi-Fi and hack worries go to secure_my_wifi, and it must not be used for product recommendations, monitoring others, or unauthorized access.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user asks "who is on my wifi", "who is using my wifi", sees an unknown device on their network, wants to identify devices connected to their router, asks "what is this device on my network", or wants a MAC address lookup (MAC address vendor) for one address. Pass the devices they pasted from their own router or app: the name and the first 6 characters of the MAC address (e.g. F0:18:98) for each; only the first 6 characters are used, and the rest of the address and the IP are not needed. For a single lookup pass one entry; if the user does not have the list yet, pass an empty list (and the router brand if known) to get the steps for finding it. Returns the maker of each device from the public IEEE registry, a likely device type, flags (private/randomized address, unknown maker, cameras and smart-home devices), which ones are worth checking, next steps and where to find the list for common routers. Do not use to scan a network, find a person or their location, monitor someone, or get into another person's network. Does not scan or connect to any network; works only from what the user tells ChatGPT.
| Name | Required | Description | Default |
|---|---|---|---|
| devices | Yes | Devices from the router or app list, one entry per row. For a single MAC address lookup, pass one entry. Pass an empty list to get the steps for finding the list on the router. | |
| routerBrand | No | Router or internet provider, if known. generic = not sure. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, it discloses the data source (public IEEE registry), the returned artifacts (maker, likely device type, private/randomized and camera/smart-home flags, next steps, router-specific instructions), and the key behavioral boundary that it never scans or connects to a network and works only from user-supplied input. This adds real context on top of readOnlyHint/idempotentHint rather than restating them.
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?
It is front-loaded with the usage trigger, then parameters, then return values, then exclusions — a sensible order for routing. It is a dense block, and the six-character MAC rule is stated twice (in prose and again via the schema), so there is minor redundancy, but nearly every clause carries actionable 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?
With no output schema, the description fully carries the burden of explaining what comes back, and it does so concretely. Combined with explicit scope exclusions and complete parameter guidance, an agent has everything needed to decide and call correctly.
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%, so the baseline is 3; the description earns slightly more by tying parameter shapes to workflows — one entry for a single lookup, an empty list plus optional brand to get instructions for finding the list. Some of the MAC-prefix detail (only first 6 characters used, IP unnecessary) duplicates the schema's own field descriptions, so it is reinforcement rather than new meaning.
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 opens with a concrete trigger set ("who is on my wifi", unknown device, MAC vendor lookup) and a specific resource: identifying devices from a pasted router list via MAC prefix. It is plainly distinguishable from the sibling tools because it explicitly rules out scanning, locating, or monitoring, leaving this as the identification/vendor-lookup tool.
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?
It gives explicit when-to-use phrasing tied to real user utterances, plus a clear when-not-to-use list (do not scan a network, find a person or location, monitor someone, or access another person's network). It also routes sub-cases: single lookup → one entry, no list yet → empty list plus router brand.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user asks how to secure their home Wi-Fi or router ("how to secure my wifi", "secure wifi from hackers", "router security settings"), how to change their Wi-Fi password or where it is shown, whether to turn off WPS or UPnP, whether to set up a guest network for smart-home devices, "can my router or internet provider see my history at home" or "do I need a VPN at home". Also use it when they suspect their own home Wi-Fi or router was hacked ("is my wifi hacked", "is my router hacked", "someone is using my wifi"): fill in the symptom answers they gave (unknown devices, a router login that stopped working, changed DNS, redirects or pop-ups, a Wi-Fi name or password that changed, slow internet, busy router lights) and use null for anything they did not say rather than guessing. Returns a router hardening checklist ranked by impact (admin password, WPA3/WPA2-AES, Wi-Fi password, firmware, WPS, remote admin, UPnP, guest/IoT network, network name, DNS), steps already done marked, brand-specific password steps and a neutral answer on privacy and VPNs at home; when symptoms are given it adds hack signals out of 100 (100 = none of the answers point to a break-in), common causes that are not a hack and ordered first steps. Do not use to hack, crack or get into a network the user does not own, to find or watch another person, to recommend VPN or security products, or for public Wi-Fi safety (use check_public_wifi_risk). Does not scan or connect to any network; works only from what the user tells ChatGPT.
| Name | Required | Description | Default |
|---|---|---|---|
| wpsOn | No | true if WPS (push-button / PIN pairing) is on. | |
| needsUpnp | No | true if a game console, voice chat or home server needs UPnP (e.g. "strict NAT" without it). | |
| smartHome | No | How many smart-home devices (cameras, plugs, bulbs, speakers, TVs) are on the network. many = moves the guest/IoT network step up. | unknown |
| dnsChanged | No | true if the router or a device shows DNS servers the user did not set. | |
| alreadyDone | No | Steps the user says they have already done; they are marked done and moved to the end. | |
| routerBrand | No | Router or internet provider, if known. | |
| slowInternet | No | true if the internet has become slow. | |
| lightsAtNight | No | true if the router lights blink a lot when nobody seems to be using it. | |
| unknownDevices | No | true if the router lists devices the user does not recognise. | |
| firmwareOutdated | No | true if router updates are not installed, or the router no longer gets updates. | |
| cantLogIntoRouter | No | true if the router admin password that used to work no longer works. | |
| redirectsOrPopups | No | true if browsers jump to odd sites, fake login pages or show pop-ups. | |
| wifiSettingsChanged | No | true if the Wi-Fi name or password changed without the user doing it. | |
| adminPasswordDefault | No | true if the router admin password is still the default one from the sticker or manual. | |
| passwordSharedWidely | No | true if the Wi-Fi password has been given to many people (neighbours, past guests, ex-roommates). | |
| redirectsOnAllDevices | No | true if the redirects/pop-ups happen on every device on this Wi-Fi, false if only on one device. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as read-only, non-destructive and closed-world, and the description adds substantial behavioral context beyond them. It describes the ranked hardening checklist, marked completed steps, brand-specific password steps, neutral privacy/VPN guidance, and the hack-signal score plus common non-hack causes when symptoms are supplied.
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 front-loaded with the primary when-to-use guidance before moving into exclusions and return behavior. It is dense and long, but given the breadth of trigger phrases and the 16-parameter schema, most of the content earns its place; it could be structured more cleanly but is not padded with fluff.
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?
For a complex 16-parameter tool with no output schema, the definition covers the important gaps: what the tool returns, how symptom inputs are handled, what the score means, and what the tool cannot do. Nothing essential for correct invocation is missing.
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%, so parameter meanings are already well documented. The description still adds useful population guidance by telling the agent to fill in symptom answers and use null for anything the user did not say rather than guessing, which is meaningful beyond the schema itself.
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 states a specific verb and resource: it helps secure a home Wi-Fi router and diagnose whether that router was hacked. It names concrete trigger phrases and explicitly distinguishes itself from check_public_wifi_risk, so an agent can tell what it does and does not cover.
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?
Usage conditions are explicit and unusually thorough: it lists when to use the tool, when not to use it (hacking someone else's network, finding or watching another person, public Wi-Fi safety), and names check_public_wifi_risk as the alternative for public networks. It also explains that it does not scan or connect to any network.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
check_public_wifi_riskidentify_wifi_devicessecure_my_wifiCompliance & security scan for your app: secrets, exposed files, headers, privacy, AI-disclosure.
Free passive security scan for AI-built apps: leaked API keys, public .env files, security headers
Independent security review for AI-built apps. Watch a GitHub repo. Never a patch.
Shopify store security: find risky scripts and apps, and turn them off from your AI agent.
Add one secure layer between your agents and this server.