NutsGrowth

Suggest a product for the directory

submit_tool

Idempotent

Send a startup or SaaS product to the NutsGrowth review queue, the way the form at /submit does. A person reads every suggestion and writes the listing by hand, so it takes days. If the website is already listed, the answer gives its page and how to claim it; if it is already in the queue, when it arrived. Fill in what you know from the product's own site; leave out what you do not. Ask the person before sending.

Input Schema

Name	Required	Description
`url`	Yes	Its website, as a full https:// address.
`name`	Yes	The product's name.
`tags`	No	Up to 8 tag slugs from list_filters. Any other is dropped, and the answer names it.
`email`	No	The person's email, only if they gave it to you for this. NutsGrowth's promise about it, as /submit makes it: "We email you once, when it is listed — with a link to claim it if it is yours — and only otherwise to ask a follow-up question. Seen only by whoever reviews the queue, never published, and in no export. Leave it blank and the submission is still read."
`price`	No	What it costs, as pricing_url shows it, which is then required. A person checks it against that page before the listing shows any price. Leave it out if the page gives no US dollar price.
`country`	No	Where the company is based: an ISO code such as "DE", or the name.
`tagline`	No	One line on what it does.
`audience`	No	Who it is for: up to 8 short labels, each at most 40 characters.
`category`	No	A category slug from list_filters.
`overview`	No	What it does, in a paragraph or two (at most 3000 characters).
`replaces`	No	Products it is a practical substitute for.
`value_prop`	No	Why somebody switches to it (at most 400 characters).
`open_source`	No	True if it is open source.
`pricing_url`	No	The page where its prices are published, as a full https:// address.
`self_hostable`	No	True if it can be run on your own servers.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 3, 2026

addedInput schema / properties / price

Added value: +{
+  "description": "What it costs, as pricing_url shows it, which is then required. A person checks it against that page before the listing shows any price. Leave it out if the page gives no US dollar price.",
+  "properties": {
+    "amount": {
+      "description": "The cheapest paid plan, in US dollars as the page states it. Never converted.",
+      "type": "number"
+    },
+    "free": {
+      "description": "Free, with no paid plan.",
+      "type": "boolean"
+    },
+    "free_tier": {
+      "description": "Has a free tier.",
+      "type": "boolean"
+    },
+    "on_request": {
+      "description": "No public price: the vendor quotes.",
+      "type": "boolean"
+    },
+    "per": {
+      "enum": [
+        "seat-month",
+        "seat-year",
+        "month",
+        "year",
+        "once",
+        "usage",
+        "transaction"
+      ],
+      "type": "string"
+    }
+  },
+  "type": "object"
+}

First observedOct 13, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Annotations only mark this as a non-destructive, idempotent write; the description adds what the annotations cannot — that a human reviews every suggestion, that turnaround is days, and that resubmitting an already-queued URL returns its arrival time (which is exactly why idempotency holds). It also discloses the handling of the optional email and the consent requirement before sending, which meaningfully de-risks an agent-initiated write.

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

Conciseness5/5

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

Four sentences, each doing distinct work: identity/equivalence, review latency, duplicate outcomes, and input discipline plus consent. It is front-loaded with the action and contains no restatement of the tool name or title.

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?

For a 15-parameter write with a nested price object and no output schema, the description covers the important unknowns: cost of the action (human review, days), duplicate behavior, and consent. It does not describe what a successful first-time submission returns, which is the one gap an agent might notice after calling.

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 the field-level semantics (tag slugs from list_filters, pricing_url required with price, USD-only amounts, character caps) are already carried by the schema. The description only adds sourcing policy — take values from the product's own site and leave gaps blank — without per-parameter detail, so the baseline of 3 is correct.

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 names a specific verb and resource — 'Send a startup or SaaS product to the NutsGrowth review queue' — and anchors it to the equivalent public form at /submit. That makes it immediately distinguishable from the sibling read tools (search_tools, get_tool, compare_tools, find_alternatives, list_filters), all of which look up rather than submit.

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?

It gives concrete operating guidance: fill in only what the product's own site supports, omit the rest, and ask the person before sending. It also handles the duplicate case by explaining that an already-listed URL returns the listing page and claim path. It stops short of explicitly telling the agent to check get_tool first, so the routing is implied rather than spelled out.

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

All NutsGrowth 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.

Resources

Need Help?