# Zenitya

> Zenitya turns your team's workflows into shared tools. Write them once in TypeScript; everyone uses them from the agent they prefer through one MCP connection, granted per group, person, or channel.

Zenitya is a small team building agentic infrastructure for artisan teams. A team packages
its workflows into tools written in TypeScript. Everyone in the organization then uses those
tools from the agent or harness they prefer, local, cloud, or custom, through one MCP
connection, and each tool is granted per group, person, or chat channel.

Packaging a workflow into a tool replaces many model turns with one deterministic call. Serving
the tools in code mode lets an agent chain them in a short script; on one measured task (median
of three runs each way) code mode used 31% fewer tokens, cost 23% less, took 26% less time, and
had 55% fewer failed calls than calling the same tools one by one.

## How it works

- Authoring: `@zenitya/sdk` (MIT, on npm). A tool is a name, a JSON schema built with `s`, MCP-style hints, and an `execute` function.
- CLI: `zya` (also `zenitya`). `zya exec --local` runs a tool against local source, `zya deploy` ships it, `zya exec` calls the deployed copy.
- Projects: a project is a unit of deployment, usually one repository. Every project's tools join the organization's single tool pool.
- Gateway (secondary): existing MCP servers such as Linear or Sentry can also be connected to the organization and served through the same endpoint and access rules.
- Endpoint: `https://mcp.zenitya.com/<org>`. People sign in with OAuth; scripts, bots, and cloud agents use service account keys.
- Modes: plain MCP lists every allowed tool. Code mode offers one tool that runs TypeScript against the pool as a typed API.
- Access: groups hold people, service accounts, and Slack or Discord channels. A chat bot passes the channel with each call, and the channel's group narrows what the bot's key reaches.
- Builds: `zya deploy` uploads source and Zenitya builds it remotely. The live version only changes once a build passes. Inputs and outputs are validated against the tool's schema.
- Runners: by default a project's tools run in Zenitya's cloud. A project can instead run on a runner the team starts on its own server or in its own cloud project (e.g. GCP), so tools can reach databases and internal APIs that live there.

## Pages

- [Home](https://zenitya.com/): the endpoint, tools as code, the MCP gateway, groups, channel scoping, code mode, and usage.
- [Developers](https://zenitya.com/developers): the CLI, the SDK, projects, builds, runners, and code mode.
- [Blog](https://zenitya.com/blog): notes and guides from the team.
- [Private beta](https://zenitya.com/early-access): request an invite.
- [Privacy Policy](https://zenitya.com/privacy): how we collect, use, and protect information.
- [Terms of Service](https://zenitya.com/terms): the terms that govern use of the Services.

## Blog posts

- [Your first Zenitya tool, from function to agent](https://zenitya.com/blog/post/your-first-zenitya-tool): Why we package workflows as tools instead of prompts, and a short walkthrough: write one in TypeScript, run it locally, deploy it, and call it from your agent.
- [A short guide to choosing the right chart](https://zenitya.com/blog/post/choosing-the-right-chart): A practical walkthrough for matching a chart type to the question you are actually answering, with the common mistakes to avoid.
- [Designing JSON schemas that survive change](https://zenitya.com/blog/post/designing-json-schemas-that-last): Practical conventions for designing JSON data formats that can evolve over time without breaking the things that read them.

## Resources

- Sitemap: https://zenitya.com/sitemap.xml
- Website: https://zenitya.com