Skip to main content
Glama

findagent_submit_for_review

Idempotent

WRITES: this is the tool that actually SUBMITS, and the draft enters human review. Not to be confused with findagent_submission_wizard, which only returns the next question to ask and changes nothing. Submit YOUR OWN draft listing for review — the final step that reaches full parity with the web submit wizard (set price, confirm originality + prohibited content, submit). Auto-detects whether the draft is built here (instructions, skills, actions) or carries code and finalizes it the same way the web wizard does: it flips your draft to pending_review (NOT published — an admin reviews it, and for an agent with code a security scan must pass, before it goes live). Pass agent (the slug or id of your draft, created via findagent_create_draft / findagent_create_code_draft), price_type/price_cents, the LLMs it targets, and BOTH confirmations. confirm_original + confirm_not_prohibited are YOUR attestation that this is your original work and avoids prohibited content (malware, illegal, or disallowed use) — both must be true, exactly like the web wizard's checkboxes. SLUG IS PERMANENT: the first time you call this WITHOUT confirm_slug it returns the exact final slug + a notice that the public URL can never change after publish; re-call it with confirm_slug set to that exact slug to acknowledge and proceed (this mirrors the web wizard's permanence confirm — you never lock a slug you didn't see). The own-work attestation (attestation: "own-work") belongs to the tools that take files you send (findagent_create_package_draft with files, findagent_reupload); the submit step takes confirm_original and confirm_not_prohibited instead. An MCP-server listing is always free: submitting one with a price is refused (listing_price_refused).

Input Schema

NameRequiredDescriptionDefault
llmsYesThe clients/LLMs this agent targets (at least one).
agentYesThe slug or id of YOUR draft (from findagent_create_draft / findagent_create_code_draft).
price_typeNoDefault free. "paid" requires price_cents (charged once Paddle is live).
price_centsNoRequired when price_type=paid: a positive integer of US cents, max 50000 ($500).
confirm_slugNoYour acknowledgement that the listing's public URL slug is PERMANENT after publish. Must exactly match the draft's slug. Call this tool WITHOUT it first to see the exact slug + permanence notice, then re-call with confirm_slug set to that slug to publish.
thumbnail_urlNoOptional. Accepted ONLY if already hosted on FindAgent assets; otherwise ignored (upload a thumbnail in the web wizard — off-site image URLs are not fetched).
confirm_originalYesRequired true — your attestation that this listing is your original work.
confirm_not_prohibitedYesRequired true — your attestation that it avoids prohibited content (no malware, illegal, or disallowed use).

Output Schema

NameRequiredDescriptionDefault
slugNo
statusNo
accountNo
submittedNo
review_urlNo
instructionsNo
thumbnail_noteNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4/5.0
Behavior3/5

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

Annotations already declare non-read-only, idempotent, non-destructive, and the description correctly adds the key state transition (pending_review, NOT published), admin review, and the security-scan gate for code agents. However, it contradicts the idempotentHint=true annotation: the first call without confirm_slug returns a notice and does not finalize, while the second call with confirm_slug does — this two-phase, argument-dependent outcome means the operation is not idempotent in effect, which the description surfaces but does not reconcile with the declared hint.

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 critical facts are front-loaded (WRITES, sibling disambiguation), which is good. But the description is a dense run-on paragraph that repeats the web-wizard parity claim multiple times, spends a long clause on attestation ownership for unrelated tools (create_package_draft, reupload), and would be far more scannable as short labeled lines.

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?

For an 8-parameter submission gate with an output schema present, the description covers state outcome, review/scan gating, slug permanence, price refusal rule, and attestation requirements. Nothing an agent needs in order to call it correctly is missing.

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?

With 100% schema coverage, the baseline is 3; the description does add real meaning beyond the schema for confirm_slug (two-call acknowledgement flow), confirm_original/confirm_not_prohibited (attestation semantics), and price on MCP-server listings (refused). Those extras justify staying at 3 rather than rising higher, since the schema already documents every parameter including the confirm_slug protocol verbatim.

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?

Opens with "WRITES: this is the tool that actually SUBMITS, and the draft enters human review," naming the verb, the resource, and the resulting state. It explicitly distinguishes itself from findagent_submission_wizard, so an agent can route 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?

Names the confusable sibling and states why it differs ("only returns the next question to ask and changes nothing"), and gives the exact two-call protocol for confirm_slug. It also states prerequisites (draft created via create_draft / create_code_draft) and an exclusion (MCP-server listings must be free).

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources