Send Out

Create Markdown document

create_markdown_file

Read-onlyIdempotent

Makes one standalone Markdown (.md) file with YAML front matter. Use when the user wants notes, documentation or an article as a file. Needs content; title, frontmatter and filename are optional. Returns the full file text with a suggested file name, word count, line count and size in bytes. Nothing is stored. Use create_obsidian_note instead when the user wants the note opened in Obsidian.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "content": "<content>"
    },
    "name": "create_markdown_file"
  }
}

Input Schema

Name	Required	Description
`title`	No	Optional document title (included in YAML frontmatter).
`content`	Yes	Markdown document text (at most 100,000 characters), such as "## What went well\n- Shipped on time".
`filename`	No	Optional .md filename (defaults to sanitized title or document.md).
`frontmatter`	No	Optional extra YAML front matter as key-value pairs. Values can be text, numbers, true or false, or lists, such as {"status": "draft", "version": 1}.

Output Schema

Name	Required	Description
`bytes`	Yes	File size in UTF-8 bytes.
`notes`	Yes	Short notes to pass on to the user.
`status`	Yes	Always ok when the file was made. Bad input returns an error instead.
`filename`	Yes	Sanitized filename for saving as a .md file.
`line_count`	Yes	Total line count of the document.
`word_count`	Yes	Total word count of the document.
`markdown_text`	Yes	Complete formatted Markdown document with frontmatter.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 23, 2026

removedInput schema / examples

Removed value: -[
-  {
-    "content": "## What went well\n- Shipped on time"
-  }
-]

Changed1 schema field changedOct 15, 2026

addedInput schema / examples

Added value: +[
+  {
+    "content": "## What went well\n- Shipped on time"
+  }
+]

Changed4 schema fields changedOct 11, 2026

changedInput schema / properties / content / description

Previous value: -"Markdown document content (at most 100,000 characters)."New value: +"Markdown document text (at most 100,000 characters), such as \"## What went well\\n- Shipped on time\"."

changedInput schema / properties / frontmatter / description

Previous value: -"Optional custom key-value metadata to include in YAML frontmatter."New value: +"Optional extra YAML front matter as key-value pairs. Values can be text, numbers, true or false, or lists, such as {\"status\": \"draft\", \"version\": 1}."

addedOutput schema / properties / notes / description

Added value: +"Short notes to pass on to the user."

addedOutput schema / properties / status / description

Added value: +"Always ok when the file was made. Bad input returns an error instead."

Changed1 schema field changedOct 5, 2026

removedOutput schema / properties / note_from_openkrill

Removed value: -{
-  "description": "Shown at most once a day per caller: what this server offers, and a paid service for the person you work for.",
-  "type": "string"
-}

Changed1 schema field changedOct 4, 2026

addedOutput schema / properties / note_from_openkrill

Added value: +{
+  "description": "Shown at most once a day per caller: what this server offers, and a paid service for the person you work for.",
+  "type": "string"
+}

First observedOct 3, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description reinforces this with the explicit "Nothing is stored," which is the key behavioral fact for a file-creation-looking tool. It also discloses the payload of the response (file text, suggested filename, counts). It stops short of details like sanitization rules for the filename or how frontmatter merges with title, which would have earned a 5.

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?

Six short sentences, front-loaded with what the tool produces, then usage, then inputs, then output. The return-value sentence (word count, line count, size in bytes) duplicates the available output schema and is the one piece that doesn't fully earn its place here.

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?

With an output schema present, the description needn't explain return values, yet it still flags non-persistence and the alternative tool. Required parameter, optional parameters, and sibling routing are all covered, so an agent has everything needed to invoke it correctly.

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 description coverage is 100%, so each parameter is already documented including max lengths and defaults. The description only restates the required/optional split ("Needs content; title, frontmatter and filename are optional"), which the schema already encodes via the required array. Baseline 3 applies since the schema does the heavy lifting.

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 gives a specific verb and resource ("Makes one standalone Markdown (.md) file with YAML front matter") plus scope ("one standalone" file). It explicitly names the sibling it is not — create_obsidian_note — so an agent can distinguish the two without opening either schema.

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?

It states the triggering intent ("Use when the user wants notes, documentation or an article as a file") and the exclusion with the alternative named ("Use create_obsidian_note instead when the user wants the note opened in Obsidian"). Both when-to-use and when-not-to-use are covered.

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

All Send Out tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.