Skip to main content
Glama
Sign In

nanoodle

by io.github.nanoodlecom
OverviewDiscussionsAdmin

humanize-comment

Draft + Context + Guidance → 5 writers (Qwen3.8 Novelist/friend, DeepSeek V4.1 Flash/forum, Cydonia-24B v4.3/peer (Starry Ocean fallback on mcp), Qwen3.8 antislop/plain, Mercury 3/quick), each with… text:Draft -> text:Context -> text:Guidance -> join:Context+Guidance -> join:Writer input -> join:Judge: context+original -> llm:Writer A (Qwen3.8-27B Novelist, voice: friend) -> llm:Writer B (DeepSeek V4.1 Flash 1017, voice: forum) -> llm:Writer C (Cydonia-24B v4.3, voice: peer) -> llm:Writer D (Qwen3.8-27B antislop, voice: plain) -> llm:Writer E (Mercury 3, voice: quick) -> join:Judge: +A -> join:Judge: +B -> join:Judge: +C -> join:Judge: +D -> join:Judge: +E -> llm:Decider (GLM-5.3); returns text. Runs on NanoGPT — a deposit is quoted for each request from its length and maxChars and caps what the customer pays; it settles at the lesser of the metered cost plus 20% and that deposit, and any difference is returned; the operator absorbs any overrun. When Cydonia fails and the Starry Ocean fallback runs, both calls are charged. This refund and cap apply to hosted payments. Direct-wallet spending has no cap; last run $0.0033, ~57s.

Input Schema

NameRequiredDescriptionDefault
keepNooptional; verbatim spans (a joke, a closing line) that must survive exactly. Each span is swapped for a placeholder before the rewrite and put back after. Every match in the draft counts, and the placeholder draft must stay within the draft cap. Overlapping keeps are protected together so each one survives. A rewrite that drops, duplicates, or changes a span is rejected. At most 8 spans, each at most 500 characters.
DraftYes* required; Text; at most 1500 characters
titleNooptional; when true, writers are asked for one title line rather than a comment; paragraph-length replies are rejected and that writer is asked once more. Default false: a short draft is not treated as a title on its own.
endingNooptional; where the rewrite must end. "question" ends with a question. "keep_last" ends with the last keep span, or with the draft's final sentence when keep is omitted. "any" leaves the ending free. default: "any"any
ContextYes* required; Text; at most 3500 characters
GuidanceNoText; default: "a friendly, specific reply"; optional; at most 600 characters; a leading one-thread prefix ("One thread: ONE main point, each sentence follows the last, 2-4 sentences <450 chars, <=1 hash/address, <=1 question at end, no 'Catch:' labels.") is not counted
maxCharsNooptional; hard cap on the rewrite length in characters (1 to 5000). Every copy of a keep span counts toward the cap. Over-length rewrites are rejected and that writer is asked once more.
_payment_idNoPayment id from this tool's previous payment-required response. Phase 3 only: after /x402/watch closes with status paid, call again with the same arguments plus this id to open the RESULTS stream. Do not pass it while payment is still pending — monitor the watch SSE first.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / title / description
      Previous value: -"optional; when true, a paragraph-length rewrite is rejected and that writer is asked once more. Default false: a short draft is not treated as a title on its own."New value: +"optional; when true, writers are asked for one title line rather than a comment; paragraph-length replies are rejected and that writer is asked once more. Default false: a short draft is not treated as a title on its own."
  2. Changed6 schema fields changed
    • changedInput schema / properties / Guidance / description
      Previous value: -"Text; default: \"a friendly, specific reply\"; optional; at most 300 characters"New value: +"Text; default: \"a friendly, specific reply\"; optional; at most 600 characters; a leading one-thread prefix (\"One thread: ONE main point, each sentence follows the last, 2-4 sentences <450 chars, <=1 hash/address, <=1 question at end, no 'Catch:' labels.\") is not counted"
    • changedInput schema / properties / Guidance / maxLength
      Previous value: -300New value: +745
    • addedInput schema / properties / ending
      Added value: +{
+  "default": "any",
+  "description": "optional; where the rewrite must end. \"question\" ends with a question. \"keep_last\" ends with the last keep span, or with the draft's final sentence when keep is omitted. \"any\" leaves the ending free. default: \"any\"",
+  "enum": [
+    "question",
+    "keep_last",
+    "any"
+  ],
+  "type": "string"
+}
    • addedInput schema / properties / keep
      Added value: +{
+  "description": "optional; verbatim spans (a joke, a closing line) that must survive exactly. Each span is swapped for a placeholder before the rewrite and put back after. Every match in the draft counts, and the placeholder draft must stay within the draft cap. Overlapping keeps are protected together so each one survives. A rewrite that drops, duplicates, or changes a span is rejected. At most 8 spans, each at most 500 characters.",
+  "items": {
+    "minLength": 1,
+    "type": "string"
+  },
+  "maxItems": 8,
+  "type": "array"
+}
    • addedInput schema / properties / maxChars
      Added value: +{
+  "description": "optional; hard cap on the rewrite length in characters (1 to 5000). Every copy of a keep span counts toward the cap. Over-length rewrites are rejected and that writer is asked once more.",
+  "maximum": 5000,
+  "minimum": 1,
+  "type": "integer"
+}
    • addedInput schema / properties / title
      Added value: +{
+  "default": false,
+  "description": "optional; when true, a paragraph-length rewrite is rejected and that writer is asked once more. Default false: a short draft is not treated as a title on its own.",
+  "type": "boolean"
+}
  3. Changed6 schema fields changed
    • changedInput schema / properties / Context / description
      Previous value: -"* required; Text"New value: +"* required; Text; at most 3500 characters"
    • addedInput schema / properties / Context / maxLength
      Added value: +3500
    • changedInput schema / properties / Draft / description
      Previous value: -"* required; Text"New value: +"* required; Text; at most 1500 characters"
    • addedInput schema / properties / Draft / maxLength
      Added value: +1500
    • changedInput schema / properties / Guidance / description
      Previous value: -"Text; default: \"a friendly, specific reply\"; optional"New value: +"Text; default: \"a friendly, specific reply\"; optional; at most 300 characters"
    • addedInput schema / properties / Guidance / maxLength
      Added value: +300
  4. Added

TDQS

C2.9/5.0
Behavior4/5

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

With no annotations, the description carries the full behavioral burden and does disclose genuinely non-obvious traits: per-request deposit quoted from length and maxChars, settlement at the lesser of metered cost plus 20% and the deposit with refund of the difference, operator absorbing overruns, the fallback being charged twice, direct-wallet spending being uncapped, and a concrete cost/latency datapoint (~$0.0033, ~57s). The gap is that the rewrite behavior itself (what a rejected rewrite means, retry semantics) is only hinted at rather than stated, and the pipeline dump crowds out more useful disclosure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The opening is a raw execution graph ('text:Draft -> text:Context -> join:Judge: +A ...') that reads as machine-generated trace output rather than a front-loaded summary. The most decision-relevant facts — what the tool does and its cost model — are buried after or inside that noise. Substantial trimming would make it far more usable.

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

Completeness3/5

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

For an eight-parameter, no-output-schema tool with a paid two-phase flow, the description covers cost, latency, and the payment-id phase transition, which is the hard part. What it omits is the selection context (versus subnano_comment) and a clear statement of the rewrite contract, leaving the agent to infer purpose from the pipeline listing.

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%, so the schema already documents all eight parameters thoroughly, including keep, ending, title, and maxChars semantics. The description adds only that request length and maxChars drive the deposit quote. Baseline 3 is appropriate; the description does not need to, and largely does not, expand parameter meaning.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description implies a rewrite/humanize operation through the five named writer voices and the 'voice: friend/forum/peer/plain/quick' labels, and it does say 'returns text'. But the actual verb+resource statement is never made plainly — the reader has to reconstruct 'rewrites a draft comment' from an internal pipeline graph. It also never distinguishes itself from the sibling subnano_comment, so selection between the two is guesswork.

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

Usage Guidelines2/5

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

There is no statement of when to choose this tool over subnano_comment or any other sibling. The only conditional guidance present is operational: the _payment_id phase-3 flow and the note that the Starry Ocean fallback double-charges. Useful, but it does not answer 'when should an agent call this'.

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

All nanoodle toolsInspect
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.

Resources