Niyra capabilities by platform

Every AI tool calls Niyra through the same MCP server, but each surface has its own quirks — what renders, what streams, what the user can do inline vs. what bounces to a Niyra channel. This page is the source of truth. Bookmark it before filing a "does X work" question.

At a glance

Legend: ✅ works as documented · 🟡 beta / partial rollout · partial = some sub-capabilities work · — = not yet supported · "channel" = approval routes to the user's primary Niyra channel (web / Telegram / Discord / WhatsApp) instead of the calling surface.

Surface notes

Claude Desktop & Claude.ai web

Anthropic's Custom Connector flow is the cleanest install Niyra has. One-click from niyra.ai/install/claude, the OAuth handshake completes in the browser, and niyra_ask is callable on the next message. Streaming text deltas render character-by-character in Claude's UI. Files attached to Claude messages get passed through to niyra_ask as part of the prompt context.

Limitations: No embedded UI widgets — Claude renders Niyra's responses as text. Long-running tasks (>30s) return a task_id and you ask Claude to poll with niyra_get_task, or you'll see the result land in your primary Niyra channel.

ChatGPT

Two installation paths. The MCP-native path (rolling out per OpenAI's Apps SDK roadmap) gives a one-click install and embedded UI widgets — Niyra responses can render inline cards, lists, action buttons. The Custom GPT path (available today) uses our OpenAPI surface at api.niyra.ai/v1/public/*; you paste the spec URL into a Custom GPT's Actions config, point auth at the OAuth flow, and you're done.

Apps SDK status: Beta. The widget surface is the killer feature here — Niyra responses with structured content can render as native UI elements inside ChatGPT instead of text walls. Phase F of the integration plan ships the manifest + widget catalog.

Cursor

Deep-link install: cursor://anysphere.cursor-deeplink/mcp/install?name=niyra&config=.... Cursor's MCP runtime keeps the connection warm so subsequent calls are sub-100ms. niyra_ask and niyra_execute both render as agent steps in Cursor's sidebar with full streaming.

Limitations: Cursor's MCP runtime has a 60s inline ceiling — anything longer hits the spawn-on-timeout path. The task_id polling works but feels less smooth than in Claude because Cursor doesn't natively prompt for the follow-up.

Cline, Windsurf, Continue, Zed

JSON-snippet install: paste a small mcpServers config into the relevant settings file (~/.vscode/mcp.json for Cline, the editor's MCP servers panel for Windsurf and Zed, ~/.continue/config.json for Continue). All five tools speak vanilla MCP over Streamable HTTP, so niyra_ask / niyra_execute / niyra_memories work the same.

Limitations: File attachments are limited — these surfaces typically don't pass binary files into MCP tool calls. Resource URIs (niyra://memory/<id>) work in Cline and Continue but are unreliable in Windsurf and unsupported in Zed as of this writing.

Claude Code

One-line install: claude mcp add niyra https://api.niyra.ai/mcp. Claude Code runs MCP calls in the terminal, surfacing Niyra's responses as inline blocks. Excellent for "while I'm in this codebase, ask Niyra to lookup that contact / draft this email" workflows.

Limitations: Long-running tasks display poorly in terminal (no UI for polling) — for anything >30s, switch to the dashboard or your primary channel.

Codex

Standard MCP config under ~/.codex/mcp.json. Works identically to Claude Code in capability terms; the UX differs only in how Codex renders progress.

Aider

Add to .aider.conf.yml as an MCP server. Limited to text-only — Aider's MCP runtime doesn't render structured content or widgets. Good for "explain this codebase change to my Niyra" use cases.

Slack (planned, Tier 3)

Not yet shipped. When live, the Slack app will:

• Install via Slack's standard OAuth + app approval flow (separate from Niyra's MCP OAuth).
• Surface niyra_ask as a slash command (/niyra what's on my calendar?).
• Use Block Kit for niyra_execute confirmations (inline Approve / Deny buttons instead of channel-bound approvals — the only surface that gets this).
• Push long-running task results back into the same Slack thread.

Why Slack gets inline approvals: Slack's Block Kit is the only AI-tool surface with first-class interactive UI for approval flows. Everywhere else, destructive operations route through the user's primary Niyra channel for confirmation; in Slack, the confirmation happens in the same workspace conversation.

What "destructive approval" means

Every Niyra tool that mutates real-world state (sending email, placing a call, modifying a calendar event) requires a separate niyra:tools:destructive scope grant and fires a per-action confirmation prompt — even with the scope granted. The confirmation is non-bypassable.

Where the confirmation lands:

• Channel-native surfaces (Slack, Telegram, Discord, WhatsApp) get the prompt with inline buttons.
• AI-tool surfaces (Claude, Cursor, ChatGPT, etc.) get the prompt in the user's pre-configured primary Niyra channel — set under Settings → Delivery.

This is intentional: a third-party app driving Niyra cannot also be the surface that approves destructive actions on the user's behalf. The user always confirms in a Niyra-owned channel.

What niyra:// resource URIs are

The MCP spec defines resource URIs as a way for tools to expose readable artifacts. Niyra publishes:

• niyra://memory/<id> — a saved memory
• niyra://conversation/<id> — a Niyra conversation transcript
• niyra://task/<id> — an agent_task row's full state (including progress history)

Surfaces that support resource URIs let the calling LLM browse these directly via resources/read without going through niyra_memories or niyra_get_task. The table above tracks which surfaces actually implement that.

Filing a support issue

If a capability appears in the matrix but doesn't work for you:

1. Check Settings → API — confirm the surface is listed under Authorized Integrations.
2. Check Settings → Activity — see whether your calls are even reaching Niyra.
3. If both look healthy, ping support with the surface name + a task_id from Activity.

If a capability is marked — or partial in the matrix and you need it: that's roadmap input, not a bug. Note your use case when you reach out.