Skip to main content
Glama
AntonioBlago

VisiblyAI MCP Server

by AntonioBlago

save_content_query_draft

Saves a sanitized editor draft for a content query using revision CAS to prevent overwrites, without publishing.

Instructions

Save an editor draft with revision CAS. The content is sanitized and nothing is published.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
titleNo
formatNohtml
contentYes
query_idYes
project_idNo
expected_revisionYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.6.1

TDQS

B3.1/5.0
Behavior3/5

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

With no annotations, the description carries the full burden and does disclose two meaningful traits: optimistic concurrency via revision CAS and content sanitization, plus the reassurance that nothing is published. It omits the failure mode when expected_revision is stale, permission requirements, and idempotency, which are important for a mutating save.

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?

Two short sentences, front-loaded with the action and the concurrency mechanism. Every clause carries information and none is wasted.

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

Completeness3/5

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

An output schema exists so return values need not be explained, and the core save semantics are covered. However, with six parameters at 0% schema coverage and no annotations, the description leaves field-level meaning and error behavior unspecified for a multi-parameter mutation.

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 0% across six parameters. The description only hints at two of them semantically (CAS maps to expected_revision, sanitization maps to content) and says nothing about query_id, title, format's html/markdown enum, or project_id, so it fails to compensate for the coverage gap.

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 specific verb (Save) and resource (editor draft) and adds the distinguishing mode (revision CAS, draft-only). An agent can tell it is a draft write rather than a publish or edit, though it never names the siblings it differs from such as submit_article_draft or update_article.

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?

There is no explicit when-to-use guidance and no conditions or alternatives. The word 'draft' weakly implies a pre-publish context, but nothing tells the agent when to choose this over submit_article_draft, update_article, or edit_content_article.

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