Skip to main content
Glama
PhononX

Carbon Voice

by PhononX
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

list_ai_actions

Read-only

Discover available AI Actions and retrieve their prompt IDs. Filter by owner type (user, workspace, system) to find the right prompt for running AI actions or summarizing conversations.

Instructions

List the AI Actions (Prompts) available to you — each has an id usable as prompt_id. USE WHEN: Before calling run_ai_action or summarize_conversation, to find a prompt_id. Also to show the user which AI Actions exist. Filter by owner_type (user = your own, workspace = shared, system = Carbon Voice built-ins). USE INSTEAD: get_ai_action_responses if you want results that were already generated rather than the list of available actions. EXAMPLE: {"owner_type":"system"} RETURNS: Array of {id, name, description?, prompt, owner_type, workspace_id?, response_format?, created_at, last_updated_at}. Use id as prompt_id elsewhere. NARROW: pass response_fields ["id","name","description","owner_type"] unless you need more — the full payload is much larger.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
owner_typeNo
workspace_idNoLimit to AI Actions owned by this workspace, from `get_workspaces_basic_info`.
response_fieldsNoDot-path allowlist to shrink the response, e.g. ["results.id","total"]. Omit for the full payload.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv2.10.0
    • addedInput schema / properties / response_fields
      Added value: +{
+  "description": "Dot-path allowlist to shrink the response, e.g. [\"results.id\",\"total\"]. Omit for the full payload.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
    • addedInput schema / properties / workspace_id / description
      Added value: +"Limit to AI Actions owned by this workspace, from `get_workspaces_basic_info`."
  2. First observed

TDQS

A4.9/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description is consistent. It adds valuable behavioral context by detailing the return structure (array of specific fields) and warns that the full payload is much larger, advising response_fields to narrow it. This goes beyond annotations and helps the agent understand response size and how to control it.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with clear sections (USE WHEN, USE INSTEAD, EXAMPLE, RETURNS, NARROW) and every sentence adds essential information. It is front-loaded with the core purpose and routes to alternatives early. No redundancy or fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple list tool with no output schema, the description fully covers the return format, filtering options, example usage, and performance guidance. It leaves nothing an agent needs to call the tool correctly, including how to handle the potentially large payload.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 67%, and the description compensates by explaining owner_type (which only has an enum in the schema) with the meaning of each value (user, workspace, system) and providing an example. It also explains the purpose of response_fields as a dot-path allowlist to shrink the response. Workspace_id is already documented in the schema, so the description adds value for the remaining parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists AI Actions (Prompts) and explicitly distinguishes it from get_ai_action_responses, which retrieves already-generated results. It provides a specific verb-resource pair and names the sibling it is not, making selection unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It provides explicit when-to-use guidance: before calling run_ai_action or summarize_conversation to find a prompt_id, and to show available AI Actions. It also gives a clear alternative (get_ai_action_responses) and explains the filtering by owner_type with an example, leaving no inference required.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools