Makeroo

Submit listing

submit_listing

Read-only

Step 1 of 2 for submitting a product to Makeroo on the maker's behalf. Only submit what you verified from the product's repo or site. Validates the details and returns a preview plus a confirmationToken. Stores and emails nothing. Show the maker the preview and the recipient email, and only after they explicitly confirm call confirm_submission.

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": {
      "name": "<name>",
      "tagline": "<tagline>",
      "description": "<description>",
      "url": "<url>",
      "category": "<category>",
      "makerEmail": "<makerEmail>"
    },
    "name": "submit_listing"
  }
}

Input Schema

Name	Required	Description
`url`	Yes	Public http(s) URL of the product
`name`	Yes	Product name, 2-60 chars
`tags`	No	Up to 5 short tags
`logoUrl`	No	Public http(s) URL of a logo
`pricing`	No	Pricing model, only if verified; omit when unsure
`repoUrl`	No	Public GitHub, GitLab or Codeberg repo of an open-source product
`tagline`	Yes	One line pitch, 5-100 chars
`category`	Yes	Category id from list_categories
`platforms`	No	Platforms it runs on; api_cli covers APIs, SDKs and CLIs; omit when unsure
`makerEmail`	Yes	Contact email of the maker; receives a confirm link once confirm_submission runs
`openSource`	No	Whether the product is open source, only if verified; omit when unsure
`description`	Yes	Plain description of what it does, 20-2000 chars

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 3, 2026

changedInput schema / properties / makerEmail / description

Previous value: -"Contact email of the maker; receives a confirm link"New value: +"Contact email of the maker; receives a confirm link once confirm_submission runs"

First observedOct 21, 2026

TDQS

A4.7/5.0

Behavior4/5

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

With readOnlyHint=true already declared, the description adds the crucial behavioral fact that this call stores and emails nothing — it only validates and returns a preview plus a confirmationToken. It also discloses the side effect that only happens later (makerEmail receives a confirm link once confirm_submission runs). It does not describe error or validation-failure behavior, keeping it below 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.

Conciseness5/5

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

Five short sentences, front-loaded with the step position and immediately followed by the verification constraint and the handoff instruction. Every sentence carries an actionable rule; nothing is repeated from the schema or annotations.

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?

No output schema exists, and the description still explains what comes back (preview plus confirmationToken), what does not happen (no storage, no email), and which tool continues the flow. For a 12-parameter submission tool this covers everything an agent needs to call it correctly and safely.

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 per-field meaning is already handled, but the description adds a cross-cutting constraint on what values may be supplied at all: only what was verified from the repo or site, which is what governs the optional pricing, openSource, and platforms fields. That is real meaning beyond the schema, though it is not field-specific guidance.

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?

"Step 1 of 2 for submitting a product to Makeroo on the maker's behalf" states a specific verb, resource, and position in a two-step flow. It also names the sibling it hands off to (confirm_submission), so an agent can distinguish it from get_submission_status or search_listings without opening any 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?

Usage is explicitly bounded: only submit details verified from the product's repo or site, show the maker the preview and recipient email, and call confirm_submission only after explicit confirmation. The when-not (no confirmation yet) and the alternative (confirm_submission) are both spelled out.

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

All Makeroo 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?