Skip to main content
Glama

List Drafts

aidelly_list_drafts
Read-onlyIdempotent

List workspace drafts with optional platform filtering. Drafts are saved as work-in-progress content and never publish.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNo
queryNoOptional query overrides for endpoints with sparse parameter schemas.
cursorNo
offsetNo
brand_idNo
platformNo
workspace_idNoWorkspace to operate in: the `id` of a workspace returned by aidelly_list_workspaces. Optional for read operations; required when creating content.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / workspace_id / description
      Previous value: -"Workspace to operate in. Do not ask the user for this UUID — call aidelly_list_workspaces and use the `id` of the matching workspace. Optional for read operations; required when creating content."New value: +"Workspace to operate in: the `id` of a workspace returned by aidelly_list_workspaces. Optional for read operations; required when creating content."
  2. Changed2 schema fields changed
    • addedInput schema / properties / cursor
      Added value: +{
      +  "maxLength": 512,
      +  "type": "string"
      +}
    • removedInput schema / properties / platform / description
      Removed value: -"Platform name to filter by (e.g., 'twitter', 'instagram')."
  3. Added

TDQS

C2.9/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint, so safety is covered. The description adds one genuinely useful semantic fact — that drafts are work-in-progress and never publish — which helps separate them from scheduled posts, but says nothing about pagination, ordering, or scope beyond the phrasing 'workspace drafts'.

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

Conciseness4/5

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

Two short sentences, no padding, with the core action front-loaded. Slightly terse given the tool's 7-parameter surface, but nothing is wasted.

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

Completeness2/5

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

With 7 parameters, no output schema, and low schema coverage, the description should at minimum explain pagination (limit/offset/cursor) and workspace/brand scoping. Neither is addressed, leaving significant gaps for a listing tool that returns an unbounded collection.

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

Parameters2/5

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

Schema description coverage is only 29% across 7 parameters, so the description needs to compensate and largely doesn't. It mentions platform filtering but leaves limit, offset, cursor, brand_id, query, and workspace_id semantics unexplained — notably the brand/workspace scoping that determines what 'workspace drafts' means.

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

Purpose4/5

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

States a clear verb+resource ('List workspace drafts') plus a scoping capability ('optional platform filtering'). It doesn't distinguish itself from sibling list tools like aidelly_list_posts or aidelly_list_ideas, but the resource is unambiguous.

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

Usage Guidelines2/5

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

No guidance on when to use this versus aidelly_get_draft, aidelly_list_posts, or aidelly_list_ideas, and no stated prerequisites. The agent must infer usage entirely from the name and siblings.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.