Productivity integration tools

This page documents the productivity integration tools your Revka agent can use to read and write the SaaS systems your team already runs on: notion, jira, google_workspace, microsoft365, composio, and linkedin. Each is a single tool that dispatches to many actions, and each is opt-in and credential-gated — a tool only registers when you enable it in config.toml (or, for Composio, set its API key). Until then the tool is invisible to the agent.

Use this page when you need the exact actions a tool accepts and the config keys that enable it. For the broader tool catalog see Tools overview; for how these same tools are exposed to external CLIs over MCP see Revka as an MCP server and Integration catalog. The integrations page in the dashboard surfaces live status — see Skills, tools & integrations pages. The config keys here are also covered in Config: channels, tools & integrations.

Note

These tools are part of the MCP server’s extended registry: they register whenever matching credentials are present, so they are reachable from both the in-process agent loop and any external MCP client. Write actions are subject to Revka’s security model — mutating operations run under the Act policy and require approval (or approved: true) in supervised mode. See Autonomy levels & approvals and the Security model.

How credentials resolve

Most of these tools accept their secret in two places: a config key in config.toml and an environment variable. When both are set, the config key wins if it is non-empty, otherwise the env var is used. Revka does not auto-load .env — export the variables yourself (or use a tool like direnv). Keep secrets encrypted at rest with secrets.encrypt = true (see Secrets, pairing & device auth).

Tool	Config key	Env var
notion	notion.api_key	NOTION_API_KEY
jira	jira.api_token	JIRA_API_TOKEN
composio	composio.api_key	COMPOSIO_API_KEY
microsoft365	microsoft365.client_secret	— (Azure app secret)
linkedin	(see [linkedin])	LINKEDIN_*
google_workspace	— (uses the gws CLI’s own auth)	—

Notion

The notion tool reads and writes a Notion workspace through the Notion REST API (https://api.notion.com/v1, API version 2022-06-28, 30s timeout).

[notion]
enabled = true
api_key = ""   # or set NOTION_API_KEY

The integration must be invited into any Notion workspace or page you want it to reach — sharing is managed in Notion, not in Revka.

Actions (action field):

Action	Policy	Purpose
search	Read	Search pages and databases in the workspace
query_database	Read	Query a database with filters
read_page	Read	Read a page’s properties
read_block_children	Read	Read the blocks inside a page
create_page	Act	Create a new page
update_page	Act	Update page properties
append_block	Act	Append blocks to a page

{ "action": "search", "query": "product roadmap" }

Jira

The jira tool talks to the Jira REST API v3 to read and search issues and post comments. It works with Atlassian Cloud (https://yourcompany.atlassian.net) using an email plus an API token.

[jira]
enabled = true
base_url = "https://yourcompany.atlassian.net"
email = "[email protected]"
api_token = ""   # or set JIRA_API_TOKEN
timeout_secs = 30
allowed_actions = ["get_ticket", "search_tickets", "comment_ticket", "list_projects", "myself"]

Actions are gated by allowed_actions — only get_ticket is available unconditionally; every other action must be listed explicitly.

Action	In allowed_actions?	Policy	Purpose
get_ticket	always allowed	Read	Fetch an issue by key
search_tickets	opt-in	Read	Search issues with JQL
comment_ticket	opt-in	Act	Post a comment on an issue
list_projects	opt-in	Read	List accessible projects
myself	opt-in	Read	Verify the configured credentials

comment_ticket mutates Jira, so it requires approved: true or supervised-mode approval. Issue keys are format-validated before any request is made.

{ "action": "search_tickets", "jql": "project = BACKEND AND status = 'In Progress'" }

Google Workspace

The google_workspace tool wraps the external gws CLI to give the agent structured access to Drive, Gmail, Calendar, Sheets, Docs, and more. It requires shell access, and the gws binary must be installed and authenticated first:

npm install -g @googleworkspace/cli
gws auth login

[google_workspace]
enabled = true
default_account = "[email protected]"
allowed_services = ["gmail", "drive", "calendar", "sheets", "docs"]
credentials_path = ""
rate_limit_per_minute = 60
timeout_secs = 30
audit_log = false

[[google_workspace.allowed_operations]]
service = "gmail"
resource = "users"
sub_resource = "messages"
methods = ["list", "get"]

Key	Type	Default	Meaning
enabled	bool	false	Register the tool
allowed_services	array	(built-in default set)	Services the agent may call
allowed_operations	array of tables	[]	Fine-grained per-resource method allowlist
default_account	string	""	Account to act as
credentials_path	string	""	Path to credentials
rate_limit_per_minute	int	60	Client-side rate cap
timeout_secs	int	30	Per-call timeout
audit_log	bool	false	Write an audit trail of every Workspace operation

A call selects a service, resource, and method:

{
  "service": "gmail",
  "resource": "messages",
  "method": "list",
  "params": { "maxResults": 10, "q": "is:unread" }
}

Caution

Gmail operations use 4-segment gws commands, so they always need a sub_resource (e.g. users → messages) in allowed_operations. Drive and Calendar use 3-segment commands and omit sub_resource. The tool registers even when gws is not installed — it reports a “missing CLI” error at call time rather than at startup.

Microsoft 365

The microsoft365 tool calls the Microsoft Graph API for Outlook mail, Teams messages, Calendar, OneDrive, and SharePoint. It requires an Azure AD app registration with the relevant Graph permissions.

[microsoft365]
enabled = true
tenant_id = "your-tenant-id"
client_id = "your-app-id"
client_secret = ""              # required for client_credentials flow
auth_flow = "device_code"       # "client_credentials" | "device_code"
scopes = ["Mail.Read", "Calendars.Read", "Files.Read"]
token_cache_encrypted = true
user_id = "me"

Key	Notes
tenant_id / client_id	From your Azure AD app registration
client_secret	Required for the client_credentials flow
auth_flow	client_credentials (app-only) or device_code (interactive on first use)
scopes	Graph permission scopes the app holds
token_cache_encrypted	Encrypt the cached token at rest
user_id	The user to act as (me by default)

The token cache is stored next to config.toml (not in the workspace). The device_code flow prompts for interactive browser auth the first time it runs; client_credentials is non-interactive but requires the secret.

Actions (action field): mail_list, mail_send, teams_message_list, calendar_list, calendar_create, onedrive_list, onedrive_download, sharepoint_list. Lists return up to 25 items by default; OneDrive downloads are capped at 10 MB.

{ "action": "mail_list", "folder": "inbox" }

Composio

The composio tool reaches 1000+ OAuth-connected apps (Gmail, GitHub, Slack, Notion, Jira, and more) through the Composio platform. No raw OAuth tokens are stored locally — connections are managed in Composio’s dashboard and scoped by an entity_id. Actions are discovered at runtime from Composio’s v3 API; HTTPS is enforced.

[composio]
enabled = true
api_key = "comp_..."   # or set COMPOSIO_API_KEY
entity_id = "default"

Actions (action field):

Action	Purpose
list	List available actions for an app
execute	Run a specific action
list_accounts	List connected accounts
connected_accounts	Inspect connected accounts
connect	Start an OAuth connection for an app

execute accepts either exact params or a natural-language text field — Composio resolves the parameters from the text when you are unsure of the exact schema. The connected_account_id is auto-resolved when omitted.

{ "action": "execute", "action_name": "GMAIL_SEND_EMAIL",
  "text": "Send an email to [email protected] saying the report is ready" }

Note

Composio requires a one-time browser OAuth flow per app before actions work. If execute returns a missing connected-account error, call list_accounts and pass the returned connected_account_id to execute. Composio is fully optional — sovereign or local-only deployments skip it entirely.

LinkedIn

The linkedin tool reads a profile and publishes content to LinkedIn. Write actions require a LinkedIn API OAuth access token; credentials are supplied via LINKEDIN_* environment variables.

[linkedin]
enabled = true
api_version = "202502"

[linkedin.content]
persona = "tech founder"
topics = ["AI", "Rust", "open source"]
rss_feeds = ["https://example.com/feed.xml"]
github_users = ["octocat"]
github_repos = ["owner/repo"]
instructions = "Post 2-3x per week in first person"

[linkedin.image]
# image-generation config for post images

Actions (action field): create_post, list_posts, add_comment, react, delete_post, get_engagement, get_profile, get_content_strategy.

The write actions — create_post, add_comment, react, and delete_post — mutate LinkedIn and therefore require approved: true (or supervised-mode approval). The [linkedin.content] block is summarized to the agent when the tool is called, so it can shape posts to your persona, topics, and cadence — useful for scheduled, automated posting workflows.

{ "action": "create_post", "content": "Excited to share our new open-source project!" }

Verifying setup

After editing config.toml, restart the daemon and confirm the tools registered. The fastest check is the dashboard’s integrations page (see Skills, tools & integrations pages), which shows each integration’s status. If an integration didn’t register, check the daemon logs for a skipped-tool message — the usual cause is a missing credential, a missing enabled = true, or, for google_workspace, the gws CLI not being on PATH. For broader config validation run revka doctor.