ProductNow

create_document

Create a NEW ProductNow document and generate its content with AI. Use this to persist knowledge the user wants remembered or shared across sessions and teammates — decisions, specs, RFCs, plans, meeting outcomes. Search with search first so you don't duplicate an existing document; to change an existing document use edit_document instead. File the document in an existing folder. Search results include each document's folderId; pass the folderId of the closest related document. If search does not show a fit, fetch_folder the root and walk folders until you have a folderId. Leave folderId off only when the user explicitly asked for the warehouse root. If no folder fits, call create_folder under the closest existing folder and pass that new folderId. Content is generated from prompt (the full outline: numbered sections, their titles, and what each should say) and context (verbatim source material the user supplied or explicitly authorized for this ProductNow document). Generation paraphrases: if exact wording must survive, put it in context and say so in prompt. Pass templateId only when you already have one. Returns the documentId and URL; generation continues after the call returns.

Input Schema

Name	Required	Description
`name`	Yes	Document title (e.g., 'RFC: API Key Generation')
`prompt`	Yes	Generation instruction for the document, including a full document outline (with numbered sections, each with a title and content)
`context`	No	Supporting material supplied by the user or explicitly authorized for this document. ProductNow attaches it as a .txt file for generation.
`folderId`	No	Folder to file the document in. Find it with search and fetch_folder before this call. Omit only when the user explicitly asked to create the document at the warehouse root.
`templateId`	No	Template ID — pass when applying a specific template

Output Schema

Name	Required	Description	Default
`url`	Yes
`documentId`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 30, 2026

changedInput schema / properties / context / description

Previous value: -"Supporting context or notes to attach as a .txt file — read from a referenced file if the user names one"New value: +"Supporting material supplied by the user or explicitly authorized for this document. ProductNow attaches it as a .txt file for generation."

Changed1 schema field changedSep 28, 2026

changedInput schema / properties / folderId / description

Previous value: -"Folder ID to place the document in — use list_folders to find the target folder"New value: +"Folder to file the document in. Find it with search and fetch_folder before this call. Omit only when the user explicitly asked to create the document at the warehouse root."

Changed2 schema fields changedSep 28, 2026

addedInput schema / properties / templateId

Added value: +{
+  "description": "Template ID — pass when applying a specific template",
+  "type": "string"
+}

removedInput schema / properties / templateVersionId

Removed value: -{
-  "description": "Template version ID — pass when applying a specific template",
-  "type": "string"
-}

First observedSep 9, 2026

TDQS

A4.8/5.0

Behavior5/5

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

With annotations declaring readOnlyHint=false, idempotentHint=false, and destructiveHint=false, the description adds substantial behavioral context beyond the structured data. It explains that generation paraphrases content and that exact wording should be placed in `context` with an instruction in `prompt`; it also notes that the call returns a documentId and URL while generation continues asynchronously. This goes well beyond what annotations provide and helps the agent understand side effects and lifecycle.

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 description is front-loaded with the core purpose and then structured logically: when to use, folder filing workflow, content generation mechanics, and return behavior. Every sentence contributes actionable information, but the overall length is substantial and slightly dense for a tool description, which prevents a perfect score despite the absence of 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?

Given the complexity of an AI-generated document tool with five parameters, folder-discovery prerequisites, and an output schema, the description is complete. It covers the full workflow from searching for duplicates to filing the document, explains how generation uses `prompt` and `context`, and notes the asynchronous nature of the result. Nothing an agent needs to call the tool correctly 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 description coverage is 100%, so the baseline is 3, but the description adds meaningful semantics: it explains that `prompt` is 'the full outline: numbered sections, their titles, and what each should say' and that `context` is 'verbatim source material' used for generation, including the paraphrasing behavior. It also clarifies when to pass `templateId` ('only when you already have one') and provides a detailed procedure for obtaining `folderId`. These additions go beyond the schema descriptions.

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 description opens with a specific verb and resource: 'Create a NEW ProductNow document and generate its content with AI.' It then explicitly distinguishes this tool from siblings by telling the agent to use `search` first to avoid duplicates and `edit_document` to change an existing document. An agent can immediately tell what this tool does and how it differs from related tools.

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

Usage Guidelines5/5

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

The description provides explicit when-to-use guidance ('persist knowledge the user wants remembered or shared across sessions and teammates — decisions, specs, RFCs, plans, meeting outcomes'), when-not-to-use alternatives (`search` for discovery, `edit_document` for changes), and a detailed prerequisite workflow for finding a `folderId` via `search`, `fetch_folder`, or `create_folder`. It leaves no ambiguity about the recommended sequence of operations.

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

All ProductNow tools Inspect

Try in Browser

Context All Your Agents Can ShareAgents share what they learn, hand off work, and hold it when you switch models. Start with 5 GB free.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.