Provides tools for codebase investigation, branch creation, pull request management, and CI status checking on GitHub repositories.
Uses OpenAI Codex (via a ChatGPT subscription) as the AI agent to execute engineering tasks.
Enables users to interact with the Citio AI engineering teammate via Slack, allowing task requests through DMs or channel mentions.
Your own AI engineering teammate, self-hosted, living in Slack.
@mention it or DM it and ask for real engineering work (investigate a bug, dig through CloudWatch logs, fix code, open a PR) and Citio runs Claude Code or OpenAI Codex inside your own infrastructure to do it. Slack is the interface, a controlled MCP tool layer is the safety boundary, and every credential stays in your own infrastructure.
No Team or Enterprise plan required. Citio runs on an individual Claude Max/Pro or ChatGPT Go/Plus/Pro (Codex) subscription, the agent you already pay for, now working from Slack.
Quickstart · How it works · Compare · Configuration · Customize · Architecture · Contributing · Security
A Slack message becomes an investigated, tested pull request, without leaving the thread.
Most teams can already chat with an LLM. The harder problem is letting a team ask for real engineering work from Slack without handing a raw shell and a pile of credentials directly to the model.
Citio closes that gap:
💬 Slack is the user interface: DM the bot or @mention it in a channel.
🧠 Claude Code or Codex is the execution engine: the provider CLI does the reasoning and planning.
🛡️ Citio is the control plane: it owns orchestration, session handling, repo setup, AWS/GitHub access, and a controlled MCP tool layer so the agent never touches raw credentials.
🏠 Everything runs in your infra: your container, your cloud account, your keys.
The result is something that can investigate bugs, inspect logs, edit code, and open pull requests, without a human sitting in the middle of every request.
Where it runs. Citio is a self-hosted container. This first version ships a native one-command AWS Fargate deploy (on Fargate Spot by default, ~$5–11/month, or
citio pauseto $0 when idle). Running on other hosts (a cheap VPS, Fly.io / Railway, or your own homelab) and a pay-per-use serverless mode are on the roadmap.
Related MCP server: flaiwheel
Anthropic's Claude Tag (June 2026) popularized exactly this idea (@mention an AI teammate in Slack and it does the work in-thread), but it's an Anthropic-hosted service gated to Claude Team and Enterprise plans, Claude-only. Citio takes the self-hosted, bring-your-own-subscription path:
Citio | Claude Tag | |
Hosting | Your AWS account, your infra | Anthropic-hosted SaaS |
Plan required | Individual Claude Max/Pro or ChatGPT Go/Plus/Pro | Claude Team or Enterprise |
Providers | Claude Code or OpenAI Codex | Claude only |
Credentials | Stay with you, behind an MCP allowlist | Managed by the vendor |
Best for | Solo devs & small teams who self-host | Orgs already on Team/Enterprise |
If you already pay for a Claude or ChatGPT subscription, Citio puts that same agent to work from Slack, no per-seat enterprise upgrade, no handing your code and credentials to someone else's cloud.
🤝 Bring your own agent: Claude Code or OpenAI Codex, your subscription or API key.
🧰 Controlled MCP tools: investigate_codebase, read_file, write_file, create_branch, create_pr, run_command (allowlisted), check_ci_status, query_logs, recall_context, and more.
🔐 Credential boundary: the agent calls MCP tools; secrets live with Citio, not the model. Command execution is allowlisted and shell-metacharacter-rejected.
🧵 Slack-native: DMs and channel mentions, streamed progress, redacted output.
💾 Persistent workspace & memory: optional AWS EFS keeps repos, sessions, and provider auth across redeploys.
🪄 One-command installer: interactive setup wires up Slack, GitHub, provider auth, and deploys to ECS.
Runtime shape:
A Slack request is normalized by the Slack adapter.
AgentRunner serializes work and manages provider sessions (one active task per container).
It spawns the Claude Code / Codex CLI as the agent, wired to Citio's MCP server via --mcp-config.
The agent uses MCP tools for codebase reads/writes, PR creation, log queries, and progress updates, never raw credentials.
Workspace, memory, and auth persist through EFS when enabled.
More detail: docs/ARCHITECTURE.md
On your machine (the installer hard-checks for Docker, AWS CLI, and Git):
Tool | Version / note |
Node.js | ≥ 22 |
Docker | Running. The image is built |
AWS CLI | v2, authenticated with a profile that has the permissions below, see Setting up your AWS profile. |
Git | Any recent version. |
The agent CLIs (
claude,codex),gh, andjqship inside the container image: you don't install them on the host.
Accounts & tokens
An agent subscription: Claude Max/Pro, or ChatGPT Go/Plus/Pro for Codex (API key works as a fallback).
A Slack app (the installer can create it for you from a config token) + the target channel ID.
A GitHub fine-grained PAT with contents: write + pull_requests: write on the repos you want worked on.
Citio deploys into your own AWS account. This takes about 10 minutes from "no AWS CLI" to "ready to install". If aws sts get-caller-identity already prints your account ID, skip to Permissions.
OS | Command |
macOS |
|
Ubuntu/Debian |
|
Windows |
Verify with aws --version (v2.x recommended).
No AWS account yet? Create one at aws.amazon.com. Then pick one route:
Option A: IAM user + access key (simplest for a personal account)
AWS Console → IAM → Users → Create user (e.g. citio-admin)
Attach permissions (see Permissions below)
Open the user → Security credentials → Create access key → choose Command Line Interface (CLI)
Configure the profile:
aws configure --profile citio
# AWS Access Key ID: AKIA...
# AWS Secret Access Key: ...
# Default region name: eu-west-2 # any region you like
# Default output format: jsonOption B: IAM Identity Center / SSO (if your org uses it)
aws configure sso # follow the browser prompts
aws sso login --profile citioVerify either way: this must print your account ID:
aws sts get-caller-identity --profile citioThe installer lists your profiles automatically and re-runs this check before it touches anything.
The deploy creates an ECR repository, an ECS cluster/service/task definition, an IAM task role, a security group, CloudWatch log groups, a Secrets Manager secret, and (optionally) an EFS filesystem.
Service | What Citio does with it |
ECR | Pushes the Citio container image to a private repo. |
ECS | Creates the cluster, task definition, and Fargate service that runs the agent. |
EC2 | Creates one security group in your default VPC. |
IAM | Creates the task role the container runs as (scoped to |
Secrets Manager | Stores your Slack / GitHub / provider tokens in |
CloudWatch Logs | Container logs, plus the agent's |
EFS (optional) | Persists agent credentials and workspace across restarts. |
Simplest (personal/sandbox account): attach the AWS-managed AdministratorAccess policy to your IAM user and skip the JSON below.
Least-privilege (shared or work account): attach this policy instead; it is scoped to exactly what the installer calls, and nothing more.
{
"Version": "2012-10-17",
"Statement": [
{ "Sid": "STS", "Effect": "Allow", "Action": ["sts:GetCallerIdentity"], "Resource": "*" },
{ "Sid": "ECR", "Effect": "Allow", "Action": ["ecr:GetAuthorizationToken", "ecr:CreateRepository", "ecr:DescribeRepositories", "ecr:BatchCheckLayerAvailability", "ecr:InitiateLayerUpload", "ecr:UploadLayerPart", "ecr:CompleteLayerUpload", "ecr:PutImage", "ecr:BatchGetImage", "ecr:GetDownloadUrlForLayer"], "Resource": "*" },
{ "Sid": "ECS", "Effect": "Allow", "Action": ["ecs:CreateCluster", "ecs:RegisterTaskDefinition", "ecs:CreateService", "ecs:UpdateService", "ecs:DescribeServices", "ecs:DescribeTasks", "ecs:ListTasks", "ecs:RunTask"], "Resource": "*" },
{ "Sid": "EFS", "Effect": "Allow", "Action": ["elasticfilesystem:CreateFileSystem", "elasticfilesystem:DescribeFileSystems", "elasticfilesystem:CreateMountTarget", "elasticfilesystem:DescribeMountTargets"], "Resource": "*" },
{ "Sid": "EC2", "Effect": "Allow", "Action": ["ec2:DescribeVpcs", "ec2:DescribeSubnets", "ec2:DescribeSecurityGroups", "ec2:CreateSecurityGroup", "ec2:AuthorizeSecurityGroupIngress"], "Resource": "*" },
{ "Sid": "Logs", "Effect": "Allow", "Action": ["logs:CreateLogGroup", "logs:DescribeLogGroups", "logs:GetLogEvents", "logs:FilterLogEvents", "logs:StartLiveTail"], "Resource": "*" },
{ "Sid": "Secrets", "Effect": "Allow", "Action": ["secretsmanager:CreateSecret", "secretsmanager:PutSecretValue", "secretsmanager:DescribeSecret", "secretsmanager:DeleteSecret"], "Resource": "arn:aws:secretsmanager:*:*:secret:citio/*" },
{ "Sid": "IAM", "Effect": "Allow", "Action": ["iam:CreateRole", "iam:GetRole", "iam:PutRolePolicy", "iam:AttachRolePolicy", "iam:PassRole"], "Resource": "arn:aws:iam::*:role/citio*" }
]
}The one people miss:
iam:PassRolescoped torole/citio*. Without it the ECS task can't assume the role the installer just created, and the deploy fails withAccessDenied.
Use whichever region is closest to you. The installer auto-detects your CLI's default and offers it. All Citio resources land in one region; remember which, for teardown.
Fastest: one command (uses the published package, no clone, no build):
npx @lawrencehui/citioInstalled globally (npm i -g @lawrencehui/citio) the command is just citio, citio status, citio destroy.
Or build from source (to read/modify the code first, or to contribute):
git clone https://github.com/lawrencehui/Citio.git
cd Citio
npm ci
npm run build
npm run initBoth launch the same guided installer, which will:
collect provider and auth settings (subscription OAuth first, API key as fallback)
collect Slack and GitHub credentials (stored in your OS keychain when available)
let you select which repos the agent can work on
write a local citio.yaml
build the image and deploy it to AWS ECS
Citio runs on Fargate Spot by default, roughly 70% cheaper than on-demand. Fargate bills per second, so cost tracks how long the task actually runs.
Task size ( | Spot (default) | On-demand | Good for |
0.5 vCPU / 1 GB ( | ~$5/mo | ~$18/mo | light/personal, small repos |
1 vCPU / 2 GB (default) | ~$11/mo | ~$36/mo | most use; bump memory if a big repo OOMs |
2 vCPU / 8 GB ( | ~$26/mo | ~$85/mo | large monorepos / heavy tasks |
Plus pennies for ECR storage and EFS (~$0.30/GB-mo). Not free-tier.
You rarely pay the monthly figure. Two ways to keep it near zero:
citio pause # scale to 0 tasks, compute charges stop, deployment + EFS stay
citio resume # back in ~1–2 min
citio destroy -- --yes --delete-efs # remove everythingA one-hour demo session costs well under $1.
Spot note: AWS can reclaim a Spot task (rare, 2-minute warning). Citio posts a "restarting, please re-send" notice and comes back automatically, fine for a single-instance bot. Want no interruptions? Set
deploy.aws.use_spot: falseincitio.yamlfor on-demand.
citio destroy -- --yes --delete-efsOr by hand, if you'd rather see every call:
aws ecs update-service --cluster citio --service citio --desired-count 0
aws ecs delete-service --cluster citio --service citio
aws ecs delete-cluster --cluster citio
aws ecr delete-repository --repository-name citio --force
aws secretsmanager delete-secret --secret-id citio/runtime --force-delete-without-recovery
# if you enabled EFS (find the ID first):
aws efs describe-file-systems --creation-token citio-memory --query 'FileSystems[0].FileSystemId'
aws efs delete-file-system --file-system-id <fs-...> # delete mount targets first if promptedThe installer generates a local citio.yaml. The committed citio.example.yaml shows the full shape:
name: citio
engine:
default_provider: claude # or "codex"
max_concurrent_sessions: 1
slack:
bot_token: ${SLACK_BOT_TOKEN}
app_token: ${SLACK_APP_TOKEN}
channel_id: C0123456789
workspace:
repos:
- url: https://github.com/your-org/your-repo.git
branch: main
rules:
- Always create PRs for code changes. Never push directly to main.
deploy:
provider: aws
aws:
region: eu-west-2
ecr_repo: citio # AWS resource names are yours to choose⚠️
citio.yamlholds local machine state (and is.gitignored). Don't commit it.
Runtime environment variables
Variable | Purpose |
| Path to the config file (default |
| Base64-encoded config (used by ECS, no file mount) |
| Workspace path (default |
| Memory/audit path (default |
🔐 Tokens are not stored as plaintext env vars. Your Slack, GitHub, and provider tokens are written to an AWS Secrets Manager secret (
citio/runtime) and injected into the container by ECS at start, so they are not readable viaecs:DescribeTaskDefinition. The values above are non-sensitive runtime config only.
Yes, a Citio instance is configured almost entirely through citio.yaml (the installer writes it for you, and you can hand-edit then redeploy). The main knobs:
Setting | Where | What it controls |
Provider |
|
|
Agent rules |
| Plain-English guardrails injected into the agent ("always open PRs", "check logs before editing", your own policies) |
Repos |
| Which repos (and branches) the agent may clone and work on |
Who can use it |
| Restrict channel |
Session limits |
| How long a task can run; how many run at once (1 = strictly serialized) |
Skills |
| Optional community skill packs the agent can use |
Commit identity |
| Author on commits the agent makes |
Bot name | Slack app manifest (set at install) | The |
AWS sizing & names |
| Container resources and the names of the resources Citio provisions |
The fastest way to change behavior is usually workspace.rules: those instructions shape how the agent investigates, edits, and reports. After editing citio.yaml, re-run npm run init (or restart the container) to apply.
See citio.example.yaml for the full annotated shape.
Area | Support |
Providers | Claude Code, OpenAI Codex |
Deploy | AWS ECS / Fargate, AWS ECR |
Persistence | Optional AWS EFS for workspace, memory, and provider auth |
Citio is currently AWS-first. Multi-cloud support is not part of the current public release.
npm run typecheck # tsc --noEmit
npm run build # compile to dist/
npm run test # node:test suite
npm run dev # run locally with tsxThe PR Citio opened (real, reviewable work on GitHub):
Working in a channel: @mention it where your team already talks:
The installer: one guided command from zero to deployed:
Citio is pre-1.0. This release deploys natively to AWS Fargate (Spot by default for low cost); the container itself is host-agnostic, so more deploy targets are coming.
✅ Slack-native control plane for Claude Code / Codex
✅ Controlled MCP tool layer with audit log
✅ One-command AWS Fargate installer (Fargate Spot default) with optional EFS persistence
✅ citio pause / citio resume / citio destroy for cost control
⏳ Not yet a hardened sandbox (provider CLIs retain native shell inside the container)
⏳ One active agent task per container
⏳ Native deploy target is AWS Fargate today, on the roadmap: run on any Docker host (VPS / Fly / Railway / homelab) and a pay-per-use serverless (Slack HTTP → Lambda → on-demand task) mode for ~$1–3/month
Citio is not a fully hardened multi-cloud platform yet. Treat this release as AWS-first and pre-1.0. Read this before deploying anywhere sensitive.
Security and isolation
Citio is a control plane, but the provider CLIs still retain native shell capabilities inside the container. The MCP tool layer is safer than handing an agent raw credentials, but it is not a policy-grade sandbox. Run it in an account you're willing to let an agent act in.
The installer stores secrets in your OS keychain when available, with a file fallback where no keychain backend exists.
Runtime and sessions
One active agent task runs at a time per container, intentional; the provider session is container-scoped.
Provider sessions don't survive a container restart or redeploy. Citio retries a failed resume as a fresh session, but provider-side conversation state is ephemeral.
Workspace state persists across redeploys only when EFS persistence is enabled.
Providers
Claude and Codex are both supported, but not symmetric: Claude uses CLAUDE_CODE_OAUTH_TOKEN or an API key; Codex OAuth depends on a persisted ~/.codex/auth.json.
Codex still relies on the CLI's native execution model, its surface isn't as clean as Claude's --mcp-config.
Installer and deployment
The interactive installer is meant for a trusted operator machine, not CI/CD runners.
Local citio.yaml is local machine state, don't commit it.
Symptom | Fix |
| Run |
|
|
| Your profile is missing the |
| Same cause: add the |
Docker push fails: | The installer logs into ECR for you. By hand: |
Deploy succeeds but Slack is silent | Check the app has |
Costs higher than expected | You may be on on-demand. Confirm |
Contributions are welcome; see CONTRIBUTING.md. Keep diffs small, prefer runtime-safe behavior over clever abstractions, and don't commit local machine state.
How credentials are handled
Your Slack, GitHub, and provider tokens live in AWS Secrets Manager (citio/runtime): never as plaintext task-definition environment variables, and never baked into the Docker image.
The agent reaches your systems through the MCP tool layer, not by holding credentials itself. run_command is allowlisted and rejects shell metacharacters.
Everything runs in your AWS account. No third party sees your code or tokens.
What Citio is not
It is not a hardened sandbox. The provider CLIs keep native shell access inside the container; see Known limitations. Deploy it into an account you're comfortable letting an agent act in.
Reporting
Found a vulnerability? Report it privately; see SECURITY.md. Please don't open a public issue for credential handling, auth bypass, shell injection, or sandbox escape.
Check CI/CD status of a pull request
| Name | Required | Description | Default |
|---|---|---|---|
| repo | Yes | Repository directory name under the workspace root | |
| pr_number | Yes | Pull request number to check CI status for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose behavioral traits such as read-only nature, network requirements, or what happens if CI is not configured. Minimal disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no unnecessary words. It is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description should provide more context about the return value or behavior. It currently lacks completeness for an agent to fully understand usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are already documented well. The description adds no additional meaning beyond what's in the schema properties.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Check' and the resource 'CI/CD status of a pull request'. It is specific and distinct from sibling tools like create_pr or run_command.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. It is implied by the purpose, but lacks context like 'use this for read-only status queries'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a git branch with an isolated worktree
| Name | Required | Description | Default |
|---|---|---|---|
| repo | Yes | Repository directory name under the workspace root | |
| branch_name | Yes | Name of the git branch to create |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It mentions 'isolated worktree' but does not detail behavioral traits like prerequisites (repo existence), side effects, or whether the worktree is created as a directory. The mutation intent is clear, but important context is missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no fluff. Every word contributes to the meaning, making it concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 2 parameters and no output schema, the description is minimal but adequate. It lacks explanation of what 'isolated worktree' entails or potential failures, but given the simple operation, it is reasonably complete for experienced users.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both params. The tool description adds no additional meaning beyond the schema, only noting the worktree detail. Baseline 3 is appropriate as the schema already documents the parameters well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a git branch with an isolated worktree, specifying the action and resource. However, it does not explicitly distinguish it from sibling tools like create_pr or run_command, though no other tool creates branches.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description only states what it does, leaving the agent to infer context without explicit when-to-use or when-not-to-use criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Push branch and create a GitHub pull request
| Name | Required | Description | Default |
|---|---|---|---|
| base | No | Base branch to merge into (defaults to main) | main |
| body | Yes | Pull request description in Markdown | |
| repo | Yes | Repository directory name under the workspace root | |
| title | Yes | Pull request title | |
| branch | Yes | Head branch to push and open the PR from |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries the burden. It discloses two actions (push and create PR), but lacks details on side effects, permissions needed, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the core action. It is concise, though slightly under-specified for a multi-action tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, and the description is minimal. For a tool with 5 parameters and two actions, more context (e.g., return format, expected behavior) would help the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The tool description adds no additional parameter meaning beyond the schema's own descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Push branch and create a GitHub pull request'. This specific verb+resource combination distinguishes it from siblings like create_branch or investigate_codebase.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. Does not mention prerequisites (e.g., branch must exist locally) or scenarios where this is preferred over other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the codebase for files, functions, or patterns related to a query
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | What to search for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must fully disclose behavior. It does not mention whether the operation is read-only, any authentication needs, rate limits, or return format. Only states it searches for items.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no redundant information. Could be slightly more structured (e.g., listing what it returns), but remains efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given one parameter and no output schema, the description covers the basic functionality. However, it lacks information on search scope (e.g., current directory or entire repo) and return format, which are needed for complete use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the parameter 'query' has a basic description. The tool description adds context (files, functions, patterns) beyond the schema, but does not compensate fully for missing behavioral details. Baseline at high coverage is 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches the codebase for files, functions, or patterns related to a query. It uses a specific verb ('Search') and resource ('codebase'), and distinguishes from sibling tools like read_file (specific file) or query_logs (logs).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., read_file, run_command). It does not specify when not to use it or provide any usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Record a short progress update for the current task
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Progress update text | |
| thread_key | Yes | Slack thread key or other stable conversation id |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It mentions recording an update, implying mutation, but lacks details on side effects, authentication needs, or what happens to existing updates. The description is minimally transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no extraneous information. It is front-loaded and every word is necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema or annotations, the description is adequate for a simple record action but lacks details on output, limitations, or usage context. It meets minimum viability but could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters. The description adds the qualifier 'short' but does not significantly enhance understanding beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Record' and identifies the resource as 'progress update for the current task'. It clearly distinguishes from sibling tools like create_branch or investigate_codebase, as none of them involve recording progress updates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, context, or situations where this tool should not be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Query the recorded MCP tool audit trail
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | Free-text query over audit events |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as read-only nature, required permissions, or side effects. For a query tool, it is assumed non-destructive, but this is not stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single sentence. While it avoids verbosity, it sacrifices informativeness. It is front-loaded but lacks key details that could be added without significant length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 parameters, no output schema), the description is minimal. It fails to explain the nature of audit events, return format, pagination behavior, or any constraints beyond the schema. This is insufficient for complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (only 'query' parameter described). The tool description does not add any parameter details beyond the schema. The 'limit' parameter lacks a description both in schema and description, leaving ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's verb ('Query') and resource ('recorded MCP tool audit trail'), which provides a specific purpose. It is distinguishable from a sibling like 'query_logs' which likely targets application logs, but the description does not explicitly differentiate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as 'query_logs'. The description lacks context for appropriate usage or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Query CloudWatch logs for recent events
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| region | No | AWS region; defaults to AWS_DEFAULT_REGION | |
| filter_pattern | No | Optional CloudWatch filter pattern | |
| log_group_name | Yes | CloudWatch log group name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavioral traits. It only implies a read operation ('Query') but does not mention permissions, rate limits, cost implications, or the meaning of 'recent events' in terms of time window.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no extraneous words, conveying the core purpose efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and no annotations, the description lacks context on return format, time range for 'recent', and differentiation from sibling tool 'query_audit_log'. This is insufficient for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter-level information beyond the input schema, which has 75% coverage. It does not clarify the 'limit' parameter (lacking schema description) or explain how parameters relate to 'recent events'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool queries CloudWatch logs for recent events, specifying a verb and resource. However, it does not differentiate from the sibling tool 'query_audit_log', which may have similar functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'query_audit_log'. There is no mention of prerequisites, limitations, or appropriate contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read file contents from the workspace
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Relative path from workspace root |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It only states 'Read file contents' without disclosing that it is a read-only operation, does not mention error handling, size limits, or permissions. Limited transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single, direct sentence with no unnecessary words. Perfectly concise for a simple read tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacks output schema and does not describe return values, error cases, or constraints like maximum file size. For a simple tool, this is a notable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with a clear description ('Relative path from workspace root'). The tool description adds no additional meaning beyond the schema, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Read file contents') and the resource ('workspace'), which distinguishes it from sibling tools like create_branch or run_command.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use or avoid this tool. While the purpose is clear, there is no mention of alternatives or preconditions, making it average.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recall prior findings from organizational memory
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | What to search for in memory |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description is too terse. It does not disclose whether the tool is read-only, requires authentication, returns multiple results, or any side effects. The description only repeats the tool's purpose without behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It is concise but could benefit from slightly more context without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a memory retrieval tool with no output schema and no annotations, the description is severely lacking. It fails to specify what constitutes 'organizational memory', the format of results, or how to formulate effective queries. The agent has insufficient information to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds no additional meaning beyond the parameter description 'What to search for in memory'. The baseline score of 3 is appropriate because the schema fully documents the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'recall' and resource 'prior findings from organizational memory'. It distinguishes it from sibling tools like 'save_finding' and 'query_audit_log' by implying it retrieves stored findings. However, it does not explicitly differentiate from other retrieval tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. There is no mention of prerequisites, when not to use it, or how it differs from similar tools like 'query_logs' or 'query_audit_log'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run an allowlisted command in the workspace
| Name | Required | Description | Default |
|---|---|---|---|
| cwd | No | Working directory relative to the workspace root (defaults to the workspace) | |
| command | Yes | Single allowlisted command to run (no shell metacharacters or pipes) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral disclosure burden. It mentions 'allowlisted' but does not explain what happens if the command is not allowlisted (error/block). It also omits side effects, permissions, and execution environment details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, no wasted words. However, it is perhaps too short; adding a second sentence on limitations would not harm conciseness. Still, it is efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimal given the tool's complexity (command execution, 2 parameters, no output schema). Missing info on return output, error handling, and default cwd behavior. A more complete description would include these details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description need not add param details. It adds the context of 'allowlisted' but that applies to the tool overall, not specific parameters. The description does not enhance understanding of 'cwd' or 'command' beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Run an allowlisted command in the workspace' clearly states the action (run), the resource (allowlisted command), and the scope (workspace). It effectively distinguishes from sibling tools like create_branch, read_file, or query_logs, which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use vs alternatives. For instance, if a user wants to execute multiple commands or a script, this tool is unsuitable, but the description does not indicate such limitations or point to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Save a finding to organizational memory for future reference
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes | Short topic label; becomes the memory file name | |
| content | Yes | Finding text to persist to organizational memory |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must convey behavioral traits. It mentions persistence to organizational memory but does not disclose whether overwriting occurs, if authentication is needed, or other constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence is efficient and front-loaded. No wasted words, but could incorporate more detail without bloat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two parameters, the description is somewhat adequate but lacks behavioral details (e.g., idempotency, side effects) that would fully inform an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover both parameters (topic, content) already. The tool description adds no additional meaning beyond summarizing the purpose, so baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (save) and resource (finding) with destination (organizational memory). It is specific but does not differentiate from sibling tools like recall_context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when or when not to use this tool. It lacks context about alternatives or prerequisites, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool targets a distinct action (e.g., create_branch vs create_pr, query_logs vs query_audit_log). There is no overlap; even the two query tools differ in source (CloudWatch vs MCP audit).
All names follow a consistent verb_noun pattern with snake_case, e.g., create_branch, investigate_codebase, query_logs. The verbs are imperative and clearly describe the action.
With 11 tools, the set is well-scoped for a developer workflow server. Each tool covers a distinct function without redundancy, and the count falls cleanly within the ideal 3-15 range.
The surface covers core operations (search, read, branches, PR creation, CI check, memory, logs) but lacks update/delete tools for branches, PRs, and findings. No write or edit file tools exist, and directory listing is absent, creating moderate gaps.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Build and supervise fleets of agents from Claude Code, Codex or Cursor. Connects over OAuth.
Human-in-the-loop for AI coding agents — ask questions, get approvals via Slack.
Real-time chat hub for AI agents — Claude Code, Cursor, Cline, Codex over MCP or REST.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/lawrencehui/Citio'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
