CodeWords
Build agents and automations
- Category
- Pending
- Primary Subcategory
- Pending
Integration details
Description
CodeWords lets you build, deploy, and run automation workflows and websites directly from conversation. Describe what you want to automate or build, and CodeWords handles the rest - writing the code, connecting your services, deploying to the cloud, and scheduling runs. Build full-stack web apps deployed to your own URL, or backend automations that connect to Slack, Gmail, Notion, and hundreds of other services and integrations. When something breaks, pull up the logs and fix it right from the chat.
- Integration type
- Plugin
- Verification status
- Not applicable
- Platform
- ChatGPT
- Category
- Pending
- Primary Subcategory
- Pending
- Secondary Subcategories
- None listed
- Brand
- Unknown
- Access
- Account required
- First tracked
- 2026-09-01
- Tool count
- 17
- Geography
- US
The broad Category that contains the Primary Subcategory.
The Primary Subcategory used for this profile’s headline score.
Other Subcategories where the Integration is listed.
ChatGPT Plugin Discovery Score
ChatGPT Plugin discovery is coming soon
ChatGPT can surface a Plugin when it matches a user's request.Your Plugin Discovery Score measures how often yours appears.
No spam. Unsubscribe any time.
What discovery looks like

Competitive lineup
17 tools agents can invoke
Cancel an in-flight CodeWords workflow run. Args: request_id: id of a running workflow run (from `run_workflow` with run_async=True). Constraints: - Only running runs can be cancelled. Already-completed runs return a 404-mapped failure response. - Cancellation is best-effort: the run is signalled to stop and will terminate when it next reaches a cancellable state. - The caller must have permission to cancel the run (i.e. it must be the user's run, or a run on a service the user owns). Returns: `{success, request_id, message, details?}`.
cancel_workflow
Validate a CodeWords service file before deploying it. Args: file_url: a `file_url` returned by `edit_service`. The service code is downloaded and checked. Validation covers Python syntax and imports, the PEP 723 metadata header, FastAPI app structure, Pydantic models and type hints, declared dependencies, environment-variable declarations, and CodeWords best-practice compliance. Returns: validator output including `all_passed` and a per-check report.
validate_service
Deploy a CodeWords service to the user's account. Args: file_url: file_url returned by `edit_service`. service_name: human-readable name for the service. service_id: optional. Provide an existing id to publish a new implementation of the same service; omit to create a new service (a uuid-suffixed id is generated). description: optional short description; if omitted, one is derived from the code's docstrings. visibility: - "private": only the owner can run the service. - "public": anyone with the service id can run it; source is not readable by others. - "template": same as "public" for execution, plus the source is readable and clonable. Note: visibility="template" does NOT promote a service into the public template gallery — that catalog is curated separately. change_summary: required, 3-6 words describing what changed in this version (e.g. "Added retry on 429"). Cannot be a generic word like "deployed". Returns: deployment outcome including `success`, `service_id`, `implementation_id`, `applied_visibility`, and a `warning` if the applied visibility differs from what was requested. Stable mode may also return `outcome` and `artifact_digest`.
deploy_service
Edit a CodeWords service file by applying a sequence of string replacements, then upload the result to a stable URL. Sources: - First call: pass a starting source — "workflow_skeleton" for the empty template, a CodeWords template id (e.g. "youtube_to_mp3"), or a service id the caller owns. - Subsequent calls: pass the `file_url` returned by a previous edit. Args: source: starting point or previous edit's file_url (see above). description: short summary of this edit batch (required, free text). edits: list of {old_str, new_str, replace_all} ops applied sequentially and atomically — either all succeed or none. `old_str` must be unique unless `replace_all=True`. Matching falls back through whitespace-insensitive, indent-flexible, and fuzzy strategies. target_filename: optional, first call only; defaults to a name derived from the source. return_content: if True, the response includes the post-edit file contents with line numbers. Defaults to False (a file_url is returned for download instead). Returns: `{file_url, filename, num_edits, message}`. If any edit matched non-exactly, `match_info` and `match_details` describe the strategy used and a unified diff so the caller can verify.
edit_service
Get the final output of an asynchronous CodeWords workflow run. If the run is still in progress, this call long-polls until the run completes or until `timeout_seconds` elapses. Args: request_id: the id returned by `run_workflow` (run_async=True). timeout_seconds: maximum poll duration, 1-3600 (default 300). Returns: `{request_id, output, status, error?}`. On timeout, raises 408. Large outputs are auto-uploaded to a file URL with a preview included in `output.message`.
get_workflow_output
List recent runs of one of the user's CodeWords services. Args: service_id: id of the service whose run history to fetch. limit: number of most-recent runs to return (1-100, default 10). Returns: `{success, service_id, service_name, total_requests, requests: [...]}`. Each request entry includes `id`, timestamps, HTTP status, request URL, and a snapshot of input/output if available. Use the returned `id` with `get_workflow_logs` for detailed log output of a specific run.
get_workflow_requests
List the names and metadata of secrets the current user has stored on CodeWords. Secret values are never returned by this tool. Args: service_id: optional. Scope listing to include per-service overrides. Returns: {success, count, secret_names, secrets}.
list_user_secrets
List the services owned by the current CodeWords user. Args: include_deleted: include soft-deleted services. Defaults to False. limit: max services to return, 1-100 (default 50). visibility_filter: "all" | "public" | "private" | "template". Returns: `{success, total_services, services: [{id, name, description, visibility, has_active_implementation, created_at, updated_at, tags, is_deleted}]}`.
list_user_services
List the saved implementations (versions) of a CodeWords service the user owns, including which one is currently active. Args: service_id: id of the service. Returns: `{success, service_id, service_name, active_implementation_id, total_implementations, implementations: [{id, created_at, change_summary, …}]}`. The returned `implementations` are ordered most-recent-first.
list_service_implementations
Read one or more CodeWords platform reference documents. The corpus is written for an LLM agent that is helping a user build, run, and maintain CodeWords workflows: it covers platform concepts, integration playbooks, service-structure rules, and template source code. All paths are relative to the docs root. Batching saves round-trips, but the assembled response is capped: if the docs you request total more than ~40,000 characters, the largest one is replaced by a file link instead of its content. Each doc's size is shown in brackets in the system-prompt catalog — keep a batch under that, and fetch a heavy doc (a mode guide, an API reference) on its own. Args: paths: Array of relative doc paths (e.g. ["README.md", "01-core-practices/01-introduction.md"]). Defaults to ["README.md"] which returns the table of contents. Returns: a `documents` map keyed by path with `{ content, success }`, plus a `summary` block with totals and the list of paths that failed.
consult_docs
Fetch logs for a single CodeWords workflow run, identified by request_id. Args: request_id: the id returned by `run_workflow` (run_async=True), `cancel_workflow`, or `get_workflow_requests`. follow: if True, stream logs until the run completes; if False, return the logs available right now (or up to a 30-second cap). Defaults to True. max_entries: cap on returned entries (1-10000, default 1000). **When to use this tool:** - To monitor progress of an async workflow execution - To debug issues with a workflow run - To get detailed execution information - To track long-running workflows in real-time **Cost-aware polling pattern (PREFERRED for long runs):** Each call re-sends the full set of log entries into chat context unless you pass `since_timestamp`. To avoid re-paying for entries you've already seen, capture `last_timestamp` from each response and pass it as `since_timestamp` on the next call. # initial fetch r1 = get_workflow_logs(request_id="cwr-…", follow=False) # later, only NEW entries: r2 = get_workflow_logs( request_id="cwr-…", follow=False, since_timestamp=r1["last_timestamp"], ) For quick "did anything happen?" checks, use `head_only=True` which returns just metadata (no log bodies). Returns: `{request_id, logs: [{timestamp, level, message, metadata?}], total_entries, is_complete, last_timestamp}`. `is_complete=False` indicates the cap or the time-limit was reached before the run finished; `last_timestamp` is the cursor for incremental polling.
get_workflow_logs
Run a snippet of Python in an isolated CodeWords sandbox (E2B). The sandbox is created per call, has no persistent filesystem, and is destroyed when the call returns. The same runtime is used by deployed CodeWords services, so behaviour matches production. Args: code: Python source to execute. Required for a new run; omit when reconnecting via `execution_id`. execution_id: ID returned by a previous call when status was "running". Used to reconnect to a still-running process and stream new output. Format "sandbox_id:process_id[:stdout_offset:stderr_offset]". dependencies: PyPI packages to install in the sandbox, with pinned versions, e.g. ["httpx==0.28.1"]. The CodeWords client ("codewords-client==0.4.6") is always included. secrets: names of the user's stored secrets to inject as environment variables in the sandbox. The secrets must already exist; values are injected server-side and must never be printed. max_execution_minutes: total runtime budget for the sandbox, 1-60. If a run exceeds ~4.5 minutes, the call returns with status="running" and an `execution_id`. Subsequent calls with that id return only new stdout/stderr since the previous offset, until the run completes or hits `max_execution_minutes`. Returns: `{success, exit_code, stdout, stderr, execution_time, dependencies, secrets_loaded}` on completion, or `{status:"running", execution_id, partial_stdout?, partial_stderr?, elapsed_seconds, remaining_minutes}` while still running. The sandbox runs as your CodeWords account and uses your CodeWords credits.
run_code
Execute one of the user's CodeWords workflows on the CodeWords runtime API (runtime.codewords.ai). The workflow must be a service the current user owns or a published CodeWords platform service. Args: workflow_id: the service id of the workflow to run. inputs: dict of parameters required by the workflow. The shape is defined by the workflow's input schema; resolve it via `view_service_code` or `consult_docs` on the matching template README before calling. path: optional sub-path on the workflow (e.g. "check-connection/ {app_slug}"). Defaults to the workflow's main entrypoint. method: HTTP method (default "POST"). Use "GET" for read-only endpoints such as discovery and connection checks. run_async: if False (default), waits up to `timeout_seconds` and returns the output. If True, returns immediately with a `request_id` for retrieval via `get_workflow_logs` / `get_workflow_output`. timeout_seconds: sync-mode wait, 1-3600 (default 300). is_template: True if the target service is a CodeWords platform template rather than an owned service. debug: when True, sets LOGLEVEL=DEBUG on the workflow run. Constraints: - The synchronous path enforces a ~5 minute client timeout. If the workflow takes longer the connection drops, but the run continues on the sandbox and is billed until completion or until the platform's 30-minute cap. For long-running workflows use `run_async=True` and poll with `get_workflow_output`. Returns: - Sync: `{output, logs, request_id, status, duration_seconds}`. - Async: `{output: null, logs: null, request_id, status:"started", message}`.
run_workflow
Search the CodeWords workflow-template catalog. Supports two modes: - Semantic (preferred): pass `query` with a natural-language description. Uses vector similarity to find matching templates. - Tag-based: pass `tags` with one or more tags to match. Matching is case-insensitive and supports both exact and substring match (e.g. "llm" matches "llm-integration"). `match_mode` controls OR ("any") vs AND ("all") logic. Returns: a `results` array of `{id, title, description, tags, matched_tags, match_types}` and a `summary` with `total_results`, `search_tags`, `match_mode`, and `all_available_tags`.
search_templates
Switch which implementation of a CodeWords service the user owns is the active one. All future requests against the service use the new active implementation immediately. Args: service_id: id of the service. implementation_id: id of an existing implementation of that service (see `list_service_implementations`). Returns: `{success, service_id, service_name, previous_active_implementation_id, new_active_implementation_id}`.
set_active_implementation
Track a task list for the current session. Pass the full updated list each call (the server does not retain state between calls); the response echoes the list back along with status counts so the client can render it. Args: todos: full list of task items. Each item has `content` (the task description), `status` ("pending" | "in_progress" | "completed"), and optional `substeps` (recursive todo items). Returns: `{message, status_summary: {pending, in_progress, completed}, todos: [...]}`.
todo_write
Read the source of a CodeWords service. Args: source: either a CodeWords service id (deployed service the user owns or a public template) or a file URL such as one returned by `edit_service`. The special string "workflow_skeleton" returns the empty service template. implementation_id: optional. With a service id, fetch a specific historical implementation rather than the active one. Ignored when `source` is a URL. show_line_numbers: if True, the returned `service_code` is prefixed with line numbers (and `total_lines` is included). Returns: `{success, source, source_type, service_code, ...}`. For service-id sources, also includes `service_id`, `service_name`, `implementation_id`, `is_active_implementation`, `owner_id`, `is_template`, `code_length`.
view_service_code
How do I improve a ChatGPT Plugin's discoverability?
The levers are the listing surface agents actually read: names, descriptions, keywords, tool metadata, and registry health. Which lever matters depends on where discovery breaks, which is what continuous measurement shows.
Where is this profile measured?
This profile uses the geography attached to the latest public registry snapshot: US. Locale tags are intentionally omitted.