Skip to main content
Glama
Unilytics MCP Server

Unilytics MCP Server

Official

propose_context_record

Save a draft of a client project's Context record with cited sources for consultant review; use it to add or update positioning, ICP, or competitor context without altering published data.

Instructions

Save a draft of one of a client project's Context records (for example the company's positioning, an ICP or the competitors), with the sources it comes from. The draft waits on the project's Context page, where the consultant publishes or discards it; the published Context, and what get_project_context returns, stay unchanged until then. This tool doesn't publish, discard or delete.

Use when the user asks to add something to a client's Context, or to update a Context record.

Every draft cites at least one source: Knowledge Base documents (`kb_sources`, each with the content_hash
kb_get_document returned, which is refused once the document has changed) and/or the user's own words
(`user_statements`, recorded as quotes reported by the AI, not verified). A record that already has a draft
waiting for review takes no new draft, except one that replaces this connection's own earlier draft.

Args:
    project_id: The project (from list_projects()).
    context_type: The record: a context type such as "positioning" or "icp", or its path such as
        "company/positioning.md", as get_project_context lists them.
    body: The record's full text, in Markdown. It replaces the record's text in the draft.
    based_on_revision: The published revision_number get_project_context returned for this record, or null when
        it listed the record under `missing` (never published). A record published again since is refused.
    title: Optional record title. Default: the current title, or the context type's name for a new record.
    kb_sources: Knowledge Base documents the text comes from: [{document_id, content_hash}].
    user_statements: The user's own words the text comes from, quoted exactly.
    replace_draft_number: The draft_number an earlier call returned, to replace that draft with this one.
    proposal_id: Optional UUID for this proposal. A repeat with the same proposal_id and arguments returns the
        saved draft instead of saving another; an OUTCOME_UNKNOWN error names the one it used.

[Provider: Unilytics]

Input Schema

NameRequiredDescriptionDefault
bodyYes
titleNo
kb_sourcesNo
project_idYes
proposal_idNo
context_typeYes
user_statementsNo
based_on_revisionYes
replace_draft_numberNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.1.0

TDQS

A4.7/5.0
Behavior5/5

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

Beyond the annotations, it explains the full lifecycle: the draft waits on the Context page, the published Context and get_project_context output stay unchanged, and a content_hash source 'is refused once the document has changed'. It also discloses the staleness rule for based_on_revision, the user_statements provenance caveat ('not verified'), and the proposal_id replay/OUTCOME_UNKNOWN error behavior. This is substantive behavior no annotation conveys.

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?

The lifecycle and usage rules are front-loaded, then a clean Args block covers each parameter, so the density is justified for a 9-parameter tool. It is on the long side and some phrasing (the parenthetical about the content_hash, the OUTCOME_UNKNOWN aside) could be tightened, but nothing is filler.

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 high-complexity, nine-parameter mutation with no output schema and no schema descriptions, the description still covers inputs, preconditions, refusals, and how to recover (proposal_id replay, OUTCOME_UNKNOWN naming the proposal used). Nothing an agent needs to call it correctly is missing.

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

Parameters5/5

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

Schema description coverage is 0%, so the description carries the whole burden, and it does: all nine parameters are explained with meaning beyond their names — where project_id comes from (list_projects), accepted context_type forms, that body replaces the text, that based_on_revision must be the published revision_number or null for `missing`, and that replace_draft_number is a prior draft_number. The kb_sources/user_statements provenance semantics are spelled out per-item.

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 first sentence gives a concrete verb and resource ('Save a draft of one of a client project's Context records') with examples (positioning, ICP, competitors), and it explicitly separates itself from related operations by noting it 'doesn't publish, discard or delete'. An agent can distinguish it from get_project_context and the publish/discard siblings without opening a schema.

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

Usage Guidelines4/5

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

It states a clear trigger ('Use when the user asks to add something to a client's Context, or to update a Context record') and a scope boundary (draft-only, never publishes or deletes). It also encodes the draft-collision rule (an existing waiting draft blocks a new one except a replacement of this connection's own draft). What it lacks is a named alternative for the publish/discard path the reader is told to avoid.

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