Skip to main content
Nuphos connectors do not all expose the same surface. Some are deeply integrated into the product interface, while others are primarily available to the agent through an authenticated API or CLI. This reference separates those layers so that agent access is not mistaken for a missing capability just because a dedicated page has not been built yet.

​
Status guide

Available

Supported as a first-class, production-ready capability.

Partial

Available with a narrower interface, an agent-only workflow, or another documented limitation.

Specialized

Implemented for a specific workflow rather than as a general connector capability.

Not available

No first-class implementation is currently available.
The credential connected to Nuphos remains the outer permission boundary. “Available” means Nuphos supports the capability; the agent still cannot exceed the permissions granted by that credential.

​
Cloud and infrastructure

AWS and GCP Watches use CloudWatch and Cloud Monitoring. For Tencent Cloud, Alibaba Cloud, Volcengine, and Azure, Partial means the agent can build the alert-to-webhook chain with the connected API or CLI, but Nuphos does not yet provide a dedicated Watch setup interface.

​
Monitoring and Watch

A Watch is more than read access. A complete Watch integration can create the provider-side notification path, connect it to a Nuphos webhook trigger, verify the wiring, and later clean up only the resources that Nuphos owns. Browse in Nuphos means the provider has a browsing surface in the app. That is not the same as feeding the unified Monitoring overview, which aggregates Grafana, Better Stack, and GCP Cloud Monitoring only — AWS CloudWatch and Uptime Kuma are browsed on their own pages. Available cleanup is recorded and deterministic. Partial for Uptime Kuma and other providers means the agent can build the webhook path, but setup or cleanup can include recorded manual steps. For a provider without a dedicated adapter, the agent can inspect the authenticated API or CLI schema and build the same general contract:
  1. Create or select an alert.
  2. Deliver it to a Nuphos webhook trigger.
  3. Validate the exact monitored resource.
  4. Send the incident to an approved messaging destination.
  5. Record the provider resources and any manual cleanup instructions.
Provider-specific adapters improve validation and deterministic cleanup, but they are not required for the agent to build a webhook-based monitoring flow.

​
Messaging

Messaging support has several independent layers. A connector may support agent chat without yet being an approved destination for automatic Watch notifications. Here, agent chat means that a linked user can send a message to Nuphos and receive the agent’s reply in the same connector; it does not imply feature parity with Slack.
  • Slack: proactive delivery supports DMs and channels; replies continue in the bound Slack thread.
  • Lark / Feishu: proactive delivery targets joined groups; replies continue in the bound conversation.
  • LINE WORKS: replies continue in the originating user or group conversation; arbitrary proactive sends are not exposed.
  • iMessage: replies continue in the paired chat’s Agent conversation, but iMessage has no native thread model and arbitrary proactive sends are not exposed.
  • Discord: support is specialized for cost alerts rather than general chat.
Slack is the complete reference implementation for monitoring delivery, including approved destinations, reply continuation, and files in both directions.
When a connector gains a new agent tool, dedicated interface, Watch adapter, or file capability, update this page together with the implementation so the matrix remains a description of shipped behavior rather than a roadmap.