Skip to main content
Glama

moxie.propose_doc_update

Propose a documentation file to add or update as part of YOUR current change. Records a new proposal each call (not idempotent) and does NOT modify your repository or open a PR - Moxie Docs resolves the target path and returns the path + Markdown for YOU to write into your working branch, so the docs land in the SAME PR as the code. Returns the resolved target path and the content to write. Provide either targetPath or baseSlug.

Input Schema

NameRequiredDescriptionDefault
titleYesShort human title for the documentation update.
reasonNoWhy this doc is being added or changed.
baseSlugNoSlug of an existing generated doc to update instead of supplying targetPath.
markdownYesThe documentation content (Markdown) to write to the target file.
repositoryNoThe target repository as "owner/name" (e.g. "acme/app"). Always pass this unless your token is scoped to a single repository. Matching is case-insensitive. If omitted when the token serves multiple repos, the call returns the list of repositories to choose from instead of an answer.
targetPathNoRepository-relative path to write the doc to (e.g., docs/billing.md). Omit to resolve from baseSlug.
sourcePathsNoCode paths this doc documents, for provenance.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.3/5.0
Behavior4/5

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

Goes beyond the annotations by disclosing that each call records a new non-idempotent proposal and that it does NOT modify the repository or open a PR, reconciling the tension with readOnlyHint=false. It also explains the resolution flow (Moxie resolves path, returns path + Markdown). Missing detail on rate limits or persistence lifetime.

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?

Front-loaded with the core action and then the critical behavioral caveats. Mostly efficient, though the closing sentence about return values partially restates the preceding sentence's resolution flow.

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

Completeness4/5

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

No output schema exists, so the description correctly describes the return (resolved target path and content). For a mutation-adjacent proposal tool with 7 params at 100% coverage, nothing essential to correct invocation is missing.

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?

Schema coverage is 100%, so the baseline is 3, but the description adds real value by stating 'Provide either targetPath or baseSlug', a mutual-exclusivity rule the schema itself does not express. Other parameters are left entirely to the schema.

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 (propose) and resource (documentation file to add or update) and scopes it to the caller's current change. The contrast with the sibling propose_doc_removal is clear from the naming, and the description makes explicit that this is a proposal, not an actual write.

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?

Gives strong usage context: 'as part of YOUR current change' and the rationale that docs should land in the SAME PR as the code. It does not enumerate when-not to use or name alternatives, but the intended workflow is unambiguous.

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.