Swipium

Overview Schema Source Related Servers Discussions Admin

Network state control

qa_network

Idempotent

Tests offline/online app behavior by toggling Android 11+ airplane mode, checking status, applying consent-gated changes, and restoring original state on report or shutdown.

Instructions

Test offline/online behavior via airplane mode (Android 11+). action: status, offline/online (consent-gated), restore. The original state is restored on qa_report, on restore, and on server shutdown.

Tool call template

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

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "sessionId": "<sessionId>",
      "action": "<action>"
    },
    "name": "qa_network"
  }
}

Input Schema

Name	Required	Description	Default
`action`	Yes
`approve`	No
`consentId`	No
`sessionId`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 11, 2026

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already declare non-destructive, idempotent, closed-world behavior. The description adds genuinely non-obvious traits: the Android 11+ precondition, that offline/online transitions require consent, and that the original network state is auto-restored on qa_report, on restore, and on server shutdown. That lifecycle disclosure is the main value add; what is missing is what a 'status' call returns and failure behavior if consent is denied.

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

Conciseness4/5

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

Three dense sentences with the core purpose front-loaded, followed by the action modes and the restore guarantees. Minor inefficiency in the inline 'action: ...' list, but no wasted prose.

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?

For a four-parameter tool with no output schema and no schema descriptions, the description covers the important behavioral contract (platform gate, consent, auto-restore). It leaves gaps on return values for 'status' and on how approve/consentId are supplied, which an agent would need before calling.

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 0%, so the description must compensate, and it only partly does. It enumerates the action enum values consistently with the schema and hints that consentId/approve relate to the consent gate, but sessionId and the exact role/format of approve and consentId are never explained.

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

Purpose4/5

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

States a specific verb and resource: 'Test offline/online behavior via airplane mode', with a platform constraint (Android 11+) and an enumeration of the action modes. It also ties into the sibling qa_report by noting that state is restored there, giving some differentiation, though it does not explicitly distinguish itself from device/network-adjacent siblings like qa_geolocation.

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?

Clear about the context of use (exercising offline/online behavior) and names the four action modes, flagging that offline/online are consent-gated. It does not state when NOT to use this tool or what to do if the device is below Android 11, so it stops short of full when/when-not guidance.

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