Is the Ralphieusa Idevice Wearables MCP server down?

mcp-registry/io.github.ralphieusa/idevice-wearables · v2.16.0

Also listed as github/idevicewearables/idevice-agent-examples, mcp-registry/com.idevice/wearables

healthy
Last checked 2026-10-27 10:59 UTC · handshake 272ms

As of 2026-10-27 10:59 UTC, the Ralphieusa Idevice Wearables MCP server is up with a Glimind reliability score of 71/100 (grade C). Over the last 30 days it answered 98.7% of Glimind's liveness checks. It had 118 outages in 90 days, with a median recovery of 4 minutes.

uptime (30d checks)
98.7%
checks observed
4,177
outages (90d)
118
tools
27

Wearable tech roadmaps: Apple, Meta, Samsung, Google, Oura. Claims, timelines, analysis.

Point your MCP client at this streamable-http endpoint: https://idevice.com/api/mcp

Agent-readiness: B (87/100)

B (87/100): 0 error(s), 3 warning(s) across 27 tool(s); ~7,251 tokens of tool definitions.
Scores higher than 60% of 15,796 MCP servers Glimind has audited.
Its tool list costs an agent ~7,251 tokens per session — more than 65% of servers.
88 → 87 since 2026-10-17
no tool-poisoning patterns
Schemas86
Descriptions100
Safety hints100
Token cost100
Client compatibility70
Protocol100
Reliability75
Stability20

What to fix (4)

2 tool(s) have parameters with no type (no type/enum/anyOf/$ref).

Give every parameter a "type" (or "enum"/"anyOf"). Untyped parameters make models guess — strings for numbers, objects for arrays. How to fix →

Tools: pick_between, should_i_buy

Reachable 98.7% of the time over the last 30 days; median recovery 4 min.

Agents fail over to an alternative the first time a call fails. Add health checks and restart-on-failure, and avoid cold starts on serverless hosts.

In the last 30 days: 2 tool(s) removed and 63 schema change(s).

Add new tools or optional parameters instead of renaming or removing; deprecate first (say so in the description) and remove later. Agents cache tool contracts. How to fix →

No tool declares an outputSchema.

Declare outputSchema and return structuredContent (MCP 2025-06-18+). Agents can then parse results without guessing, and chain tools reliably. How to fix →

Auto-fix: 2 corrected tool definitions

Paste-ready definitions with the problems above fixed. Changes marked verify need a human look. All of them as JSON: /v1/readiness/mcp-registry%2Fio.github.ralphieusa%2Fidevice-wearables/fixes

pick_between 1 change
{
  "name": "pick_between",
  "description": "For two or three products, which one the written buy-or-wait rules put ahead, or that neither is ahead, optionally for a shopper who owns a device or uses iPhone or Android, with a budget. Each product comes with its verdict (buy_now, wait, skip, check_fit or not_enough_data), its fit with the phone given, today's retailer price and the reasons, each with its source and how sure iDevice is. A product that does not work with the phone given goes last; then the verdict decides, then the fit answer",
  "inputSchema": {
    "type": "object",
    "$schema": "http://json-schema.org/draft-07/schema#",
    "required": [
      "product_slugs"
    ],
    "properties": {
      "budget_usd": {
        "type": "number",
        "description": "A price ceiling in US dollars",
        "exclusiveMinimum": 0
      },
      "buyer_context": {
        "description": "Optional. The shopper's own situation, in the closed grammar of the form on the idevice.com decision pages: { context_version: \"buyer-context-v1\", context, provenance }. context: currency \"USD\", risk_tolerance \"normal\", urgency (today, within_30_days, within_90_days or can_wait), priorities (up to three { id, importance }, importance must_have, high or medium; an id is a use or buying criterion the page can weigh, such as sleep, fitness or battery_life), hard_constraints (up to three: { id: \"phone_platform\", value: \"iphone\" or \"android\" }, { id: \"no_subscription\", value: true }, { id: \"max_budget\", value: a dollar amount }), cost_inputs (up to three { kind: offered_price, trade_in or required_accessories, amount, currency \"USD\", explicit_zero }), and optionally platform, expected_ownership_months (12, 24, 36 or 48), owned_condition and ecosystem_switch_willingness. Amounts are numbers from 0 to 100000 with at most two decimals. provenance: for each hard constraint, \"hard_constraints:<id>\": \"selected\" when the shopper stated it; a hard constraint without \"selected\" is not applied. The products come from this call's own arguments. A context outside the grammar is answered with buyer_decision_info naming the fields to fix, and the rest of the answer is unchanged. The context is used for this one answer and then dropped: it goes into no log.",
        "type": "string"
      },
      "product_slugs": {
        "type": "array",
        "items": {
          "type": "string"
        },
        "maxItems": 3,
        "minItems": 2,
        "description": "Two or three product_slugs, e.g. ['oura-ring-4','samsung-galaxy-ring-1']"
      },
      "owned_platform": {
        "enum": [
          "iphone",
          "android",
          "other"
        ],
        "type": "string",
        "description": "The phone platform the shopper uses"
      },
      "owned_device_slug": {
        "type": "string",
        "description": "A product_slug of a device the shopper already owns, e.g. 'iphone-17'"
      }
    },
    "additionalProperties": false
  },
  "annotations": {
    "title": "Pick between two or three products",
    "readOnlyHint": true,
    "openWorldHint": false,
    "idempotentHint": true,
    "destructiveHint": false
  },
  "title": "Pick between two or three products"
}
should_i_buy 1 change
{
  "name": "should_i_buy",
  "description": "For one product: buy now, wait, skip or check fit first, optionally for a shopper who already owns a device or uses iPhone or Android, with a budget or a use. Returns a verdict (buy_now, wait, skip, check_fit or not_enough_data) and the rule behind it, reasons that each carry a source link and how sure iDevice is (Confirmed, Reported, Our read or Not confirmed), the fit with the shopper's phone platform, timing (a newer model out, announced or reported), price (iDevice's published verdict and th",
  "inputSchema": {
    "type": "object",
    "$schema": "http://json-schema.org/draft-07/schema#",
    "required": [
      "product_slug"
    ],
    "properties": {
      "use_case": {
        "type": "string",
        "maxLength": 120,
        "description": "What it is for, e.g. 'running' or 'sleep tracking'"
      },
      "budget_usd": {
        "type": "number",
        "description": "A price ceiling in US dollars",
        "exclusiveMinimum": 0
      },
      "product_slug": {
        "type": "string",
        "description": "The product being considered, a product_slug, e.g. 'apple-watch'"
      },
      "buyer_context": {
        "description": "Optional. The shopper's own situation, in the closed grammar of the form on the idevice.com decision pages: { context_version: \"buyer-context-v1\", context, provenance }. context: currency \"USD\", risk_tolerance \"normal\", urgency (today, within_30_days, within_90_days or can_wait), priorities (up to three { id, importance }, importance must_have, high or medium; an id is a use or buying criterion the page can weigh, such as sleep, fitness or battery_life), hard_constraints (up to three: { id: \"phone_platform\", value: \"iphone\" or \"android\" }, { id: \"no_subscription\", value: true }, { id: \"max_budget\", value: a dollar amount }), cost_inputs (up to three { kind: offered_price, trade_in or required_accessories, amount, currency \"USD\", explicit_zero }), and optionally platform, expected_ownership_months (12, 24, 36 or 48), owned_condition and ecosystem_switch_willingness. Amounts are numbers from 0 to 100000 with at most two decimals. provenance: for each hard constraint, \"hard_constraints:<id>\": \"selected\" when the shopper stated it; a hard constraint without \"selected\" is not applied. The products come from this call's own arguments. A context outside the grammar is answered with buyer_decision_info naming the fields to fix, and the rest of the answer is unchanged. The context is used for this one answer and then dropped: it goes into no log.",
        "type": "string"
      },
      "owned_platform": {
        "enum": [
          "iphone",
          "android",
          "other"
        ],
        "type": "string",
        "description": "The phone platform the shopper uses"
      },
      "owned_device_slug": {
        "type": "string",
        "description": "A product_slug of a device the shopper already owns, e.g. 'iphone-17'"
      }
    },
    "additionalProperties": false
  },
  "annotations": {
    "title": "Should I buy this",
    "readOnlyHint": true,
    "openWorldHint": false,
    "idempotentHint": true,
    "destructiveHint": false
  },
  "title": "Should I buy this"
}

Get alerted

Get an email or webhook when this server's readiness drops by 10+ points, tool-poisoning text appears, or a tool breaks:

curl -X POST https://glimind.com/v1/subscriptions -H 'content-type: application/json' -d '{"tools":["mcp-registry/io.github.ralphieusa/idevice-wearables"],"email":"[email protected]"}'

Agents: watch_tool({"toolId": "mcp-registry/io.github.ralphieusa/idevice-wearables"}) over MCP.

Passed

Largest tool definitions

Static checks of the advertised tools/list (schema, descriptions, annotations, tool-poisoning patterns, names, size) plus observed protocol, uptime, latency and contract changes. Read-only: no tool is ever called. Weights: schema 15, docs 20, safety 15, efficiency 15, compatibility 15, protocol 5, reliability 10, stability 5. Token counts are estimates (~3.6 characters per token).

Operator? Fix these, then re-check live. Embed the readiness badge:

Markdown
[![MCP agent-readiness](https://glimind.com/v1/readiness/badge/mcp-registry%2Fio.github.ralphieusa%2Fidevice-wearables.svg)](https://glimind.com/server/mcp-registry%2Fio.github.ralphieusa%2Fidevice-wearables?ref=badge)
HTML
<a href="https://glimind.com/server/mcp-registry%2Fio.github.ralphieusa%2Fidevice-wearables?ref=badge"><img src="https://glimind.com/v1/readiness/badge/mcp-registry%2Fio.github.ralphieusa%2Fidevice-wearables.svg" alt="MCP agent-readiness"></a>
reStructuredText
.. image:: https://glimind.com/v1/readiness/badge/mcp-registry%2Fio.github.ralphieusa%2Fidevice-wearables.svg
   :target: https://glimind.com/server/mcp-registry%2Fio.github.ralphieusa%2Fidevice-wearables?ref=badge
   :alt: MCP agent-readiness

Tool-definition log

Glimind records every version of this server's tool definitions in a signed, append-only transparency log. Current manifest sha256:881983a20c502622…, first seen 2026-10-23, included at leaf 50529 of 78,967. Version history · verify what your client received.

Tools (27)

Compare: most reliable knowledge servers · most reliable data servers · most reliable search servers · most reliable retrieval servers · most reliable calendar servers

Know before your agent calls it

Glimind tells agents whether a server is up right now and how to call it, then fails over to a live alternative when it isn't.

Add Glimind — free, no signup:

Add to Cursor Add to VS Code

Claude Code

claude mcp add --transport http glimind https://glimind.com/mcp

Claude Desktop · Windsurf · Cline (mcpServers JSON)

{
  "mcpServers": {
    "glimind": {
      "type": "http",
      "url": "https://glimind.com/mcp"
    }
  }
}

FAQ

Is the Ralphieusa Idevice Wearables MCP server down right now?

As of 2026-10-27 10:59 UTC, the Ralphieusa Idevice Wearables MCP server is up with a Glimind reliability score of 71/100 (grade C). Over the last 30 days it answered 98.7% of Glimind's liveness checks. It had 118 outages in 90 days, with a median recovery of 4 minutes.

How many tools does Ralphieusa Idevice Wearables MCP server provide?

Ralphieusa Idevice Wearables MCP server advertises 27 tools, including check_deal, compare_products, find_best_device, find_products, get_best_for.

How do I install Ralphieusa Idevice Wearables MCP server?

Point your MCP client at this streamable-http endpoint: https://idevice.com/api/mcp

Is the Ralphieusa Idevice Wearables MCP server safe to connect to an AI agent?

Glimind scanned all 27 tool definitions for tool-poisoning patterns — hidden or invisible characters, instructions that override the model, concealment from the user, requests to read credential or MCP config files, conversation exfiltration and cross-tool shadowing — and found none. This checks what the server tells the model, not what its code does; review the source before granting access to sensitive data.

Operator of Ralphieusa Idevice Wearables MCP server?

Status page: 90-day uptime, every outage and how long it lasted.

Claim this listing to get the Verified operator marker, a remediation checklist and owner analytics, or embed the live badge from any of the tool pages above. Maintainers: alerts, deploy attestation and monthly reports.

Status is an automated estimate from Glimind's liveness checks (handshake and tool listing only; no tool is ever called) and may lag or differ from your network. Glimind is not affiliated with this server or its operator. Operator? Request a correction or opt out at https://glimind.com/opt-out.

Feedback
Help us improve