ZyndaX / Modules / Connectors
Module

Governed access to whatever your team already runs on.

MCP and A2A connectors bring outside systems into the same conversation instead of a context switch — every read permission-checked, cited, and remembered, so connector activity becomes recallable memory alongside everything else.

How it works

Two protocols, one governance model.

A2A

How the assistant talks to every internal module

People Operations, CRM, Financials, Workflows — all reached the same typed, permission-checked way, as the human user.

MCP

How the assistant reaches outside systems

External tools become governed capabilities the assistant can use — not a shared god-token, not a copy-pasted API key.

Per-user credentials

Your access, not a service account's

Every external read runs as the person asking — permission-checked against their own real access, not a broad shared credential.

ZyndaXJira · read
What's the status of FALCON-142?
Checking your Jira access
Reading the issue as you, not a shared token

In Review, cited straight from Jira — no tab switch.

ZyndaXGitLab · read
Is the staging pipeline green?
Reading pipeline status via MCP

Green, last run 12 minutes ago — permission-checked, cited.

ZyndaXGitLab · write
Comment on the MR that QA signed off.
Drafting the comment
Confirm write Post comment on MR !482? ✓ Posted · logged

Writes are never silent — always confirmed first.

Vertical-specific by design

The pattern is universal; the systems it connects to aren't.

Software teams use it for Jira and GitLab; a different vertical would use the same governed pattern for its own systems of record. See the pattern in context:

Talk to us

Ask what a connector to your own systems would look like.