Skip to main content
Glama
Sign In

LaunchDistro

by com.launchdistro
OverviewDiscussionsAdmin

Suggest a directory

suggest_directory
Idempotent

When the user recommends a directory LaunchDistro does not give for this product, send it for review. A suggestion only: do not open its form or submit there. It gets a playbook, and reaches plans, only after LaunchDistro checks it.

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": {
      "url": "<url>"
    },
    "name": "suggest_directory"
  }
}

Input Schema

NameRequiredDescriptionDefault
urlYesThe directory's site (its home or submit page).
nameNoThe directory's name, as the user or its page gives it.
noteNoWhy the user recommends it, or what they know about it (free, dofollow, niche).
productNoThe product's website or name. Leave empty for the product last worked on (list_products shows them).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already cover the safety profile (non-read-only, non-destructive, idempotent, closed-world), so the description's job is to add lifecycle context — and it does: the suggestion is gated by a LaunchDistro review and only then receives a playbook and reaches plans. That post-condition is genuinely useful for an agent deciding whether to call it. It omits any note about what the call returns or what happens on a duplicate suggestion.

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

Conciseness4/5

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

Three short sentences with no filler; the usage condition is front-loaded and the prohibition follows immediately. The grammar is noticeably tangled ('a directory LaunchDistro does not give for this product'), which slightly slows comprehension but doesn't cost information.

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 4-parameter creation tool with no output schema, the description covers the essential trigger, the misuse warning, and the downstream consequence of the call. It doesn't describe the response (e.g. whether a submission id or status comes back), but the operational essentials for calling it correctly are present.

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 all four parameters (url, name, note, product) are already documented with format hints. The description adds only light framing — 'the user recommends' gestures at note, and 'for this product' at product — but nothing about which value to pass or how the product default works beyond what the schema says. Baseline 3 applies.

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

Purpose4/5

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

The description states a concrete action — 'send it for review' a directory the product isn't already listed on — which maps to creating a suggestion record. It implicitly separates itself from record_submission ('do not open its form or submit there'), though the phrasing is oblique ('LaunchDistro does not give for this product') rather than a clean verb+resource statement.

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?

The trigger is explicit: use this 'when the user recommends a directory LaunchDistro does not give for this product.' It also supplies an explicit negative boundary ('do not open its form or submit there'), which is the key confusion risk with sibling tools like record_submission. No sibling is named directly, so it stops short of a 5.

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

All LaunchDistro 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