Skip to main content
Glama

Local MCP

by com.local-mcp
OverviewDiscussionsAdmin

Recipe Submit For Review

recipe_submit_for_review
Destructive

Submits one of YOUR saved recipes/skills to the community moderation queue for Dario's review — this does NOT publish it. Without confirm=true it PREVIEWS the title/category/apps/workflow write-up that would be sent (nothing leaves this Mac); with confirm=true it submits and returns {status:"submitted", pending:true}. Once approved it appears on /community/skills and anyone can install it with recipe_install. workflow is the public write-up: it defaults to the recipe's own description field when that's at least 15 characters, otherwise pass one explicitly.

Input Schema

NameRequiredDescriptionDefault
appsNoFree-text apps the recipe touches (e.g. "Mail, Calendar"), shown in the moderation queue.
nameYesName of the saved recipe/skill to submit (see recipe_list).
titleNoShown once approved on /community/skills. Defaults to the recipe's own name.
confirmNoMust be true to actually submit. Without it, returns a preview — nothing is sent.
categoryNoFree-text category shown in the moderation queue and, once approved, on /community/skills.
rememberNoWith confirm: true, also stop asking for this kind of action from now on. Only when the person said so ("don't ask again"). The person can revoke it in LMCP or with set_always_allowed.
workflowNoThe public write-up of what the recipe does. Defaults to the recipe's own `description` if it's at least 15 characters; required otherwise.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / remember
      Added value: +{
+  "description": "With confirm: true, also stop asking for this kind of action from now on. Only when the person said so (\"don't ask again\"). The person can revoke it in LMCP or with set_always_allowed.",
+  "type": "boolean"
+}
  2. Added

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already signal a non-read-only, open-world, potentially destructive operation, but the description adds substantial behavioral context: preview mode sends nothing off the Mac, confirm=true submits to the moderation queue, the response includes {status:'submitted', pending:true}, and approval exposes the recipe publicly for recipe_install. This is exactly the extra safety and side-effect detail an agent needs for a workflow with external effects.

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?

The description is dense but front-loaded: it starts with the core action and the critical does-not-publish caveat, then explains preview vs submit, downstream approval/install, and the workflow default. Every sentence carries operational value.

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 a 7-parameter mutation tool with no output schema, the description covers the important behavioral contract: preview vs confirmed submission, what the preview contains, the return shape on submit, approval visibility, and the workflow fallback behavior. Annotations plus this description give an agent enough to call it 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 description coverage is 100%, so the baseline is 3. The description still adds useful integrated meaning by saying the preview shows title/category/apps/workflow and by restating the workflow default rule (recipe description when at least 15 characters), but most individual parameter meaning is already present in the schema.

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 uses a specific verb+resource ('Submits one of YOUR saved recipes/skills') and explicitly distinguishes the action from publishing ('this does NOT publish it'). It also names related sibling tools recipe_install and recipe_list, so an agent can place it in the recipe lifecycle without opening other schemas.

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 clearly explains the confirm=true vs preview path and notes the downstream install step via recipe_install. However, it does not explicitly say when to use this versus other recipe tools such as recipe_save, recipe_export, or recipe_discover beyond the implicit lifecycle.

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

All Local MCP 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