Skip to main content
Glama

Get writing context

get_context
Read-onlyIdempotent

Get what this user has recorded about how they write and post: voice, audience, guardrails, product facts, posting strategy, and dated learnings about what worked. With an account_id, returns the documents that apply to that account, since voice can differ per platform. For drafting in the user's own voice and planning when posts go out.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_context"
  }
}

Input Schema

NameRequiredDescriptionDefault
account_idNoResolve the documents that apply to this connected account. Omit for the workspace-wide set.

Output Schema

NameRequiredDescriptionDefault
noteNo
documentsYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already cover read-only, idempotent, non-destructive, and closed-world behavior, so the description only needs to add scope details. It does add a genuinely useful one: that an account_id narrows results to the documents applying to that account because voice can differ per platform. Return-shape explanation is correctly omitted since an output schema exists.

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?

Three sentences, each doing work: content scope first, then account scoping, then intended use. Slight redundancy between the description's account_id clause and the schema's own wording, but overall front-loaded and free of padding.

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 zero-required-param read tool with annotations and an output schema, nothing material is missing. Purpose, contents, scoping semantics, and usage motivation are all present, so an agent can call it correctly on the first attempt.

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

Parameters3/5

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

Schema coverage is 100% and the schema description already states 'resolve the documents that apply to this connected account; omit for workspace-wide.' The description's account_id note adds the rationale (per-platform voice differences) but no syntax or new constraints, so this is baseline territory.

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?

Names a specific verb (get) and a precisely enumerated resource: voice, audience, guardrails, product facts, posting strategy, and dated learnings. The enumeration makes it distinguishable from get_briefing, bind_context, and set_context without opening any 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?

Explicitly states the use context: drafting in the user's own voice and planning post timing. It also tells the agent when to pass account_id versus omitting it. It stops short of naming when-not or an explicit alternative sibling, but the guidance is actionable.

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.

Resources