Skip to main content
Glama
PhononX

Carbon Voice

by PhononX
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

get_root_folders

Read-only

List root folders in a Carbon Voice workspace for voicememo or prerecorded types. Use to orient in the folder tree or find a folder_id, optionally including nested folders.

Instructions

List the root folders of a workspace for a given folder type. USE WHEN: Orienting in the folder tree, or finding a folder_id. type is required: voicememo or prerecorded. include_all_tree returns nested folders too. USE INSTEAD: get_folder to inspect one folder. get_folder_with_messages when you want a folder’s messages rather than its structure. EXAMPLE: {"type":"voicememo","workspace_id":"ws-abc"} RETURNS: {type, workspace_id?, include_all_tree?, sort_by, sort_direction, results: [{id, name, parent_folder_id?, subfolder_ids?, total_nested_folders_count, total_nested_messages_count, ...}]}. Not paginated — this is the complete set. NARROW: pass response_fields ["results.id","results.name","results.total_nested_messages_count"] unless you need more — the full payload is much larger.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
typeYesFolder Type
sort_byNoField to sort by
workspace_idNoWorkspace ID
sort_directionNoSort order directionASC
response_fieldsNoDot-path allowlist to shrink the response, e.g. ["results.id","total"]. Omit for the full payload.
include_all_treeNoReturn all folders tree

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field 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"
+}
  2. Changed1 schema field changedv2.8.17
    • removedInput schema / properties / sort_by / default
      Removed value: -"name"
  3. 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 adds meaningful behavioral detail: the result is not paginated, it returns the complete set, and the full payload is much larger. It also shows how to narrow output with response_fields, which goes beyond annotation data.

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 USE WHEN, USE INSTEAD, EXAMPLE, RETURNS, and NARROW sections. Every sentence contributes actionable guidance, and the most important usage details are front-loaded.

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?

Despite having no output schema, the description documents the return shape explicitly, including optional fields and non-pagination. For a 6-parameter read-only list tool, this is a complete and self-sufficient definition.

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?

Input schema covers all parameters at 100%, so the baseline is 3. The description adds value beyond the schema by giving a concrete example, clarifying type's allowed values, explaining include_all_tree's effect, and documenting response_fields behavior with an example allowlist.

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?

States a specific verb and resource ('List the root folders of a workspace') and scopes by folder type. The USE INSTEAD section explicitly names get_folder and get_folder_with_messages as distinct alternatives, so sibling differentiation is strong.

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?

Provides explicit USE WHEN conditions ('Orienting in the folder tree, or finding a folder_id'), states that type is required, and names alternatives with the conditions that select them. This leaves no ambiguity about when to invoke this tool.

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