Lune Research

Send feedback to Lune

send_feedback

Sends the user's feedback about Lune to the Lune team. Use it when the user says something about Lune itself (papers it missed, results that did not fit, an error, something that helped, an idea): offer to pass it on, show the user the message you would send, and call this only after they agree. Set allow_training only if they also agreed that Lune may train models on it, after telling them they can withdraw that at any time in their Lune account settings. Write the message from what the user said about Lune, leaving out unrelated conversation and personal details.

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": {
      "category": "<category>",
      "message": "<message>"
    },
    "name": "send_feedback"
  }
}

Input Schema

Name	Required	Description
`message`	Yes	The feedback as the user approved it: what they asked Lune for and what happened, naming the papers involved. Leave out the user's own name and contact details, credentials, and private documents.
`category`	Yes	missing_papers: Lune did not find papers the user expected. irrelevant_results: the results did not fit the question. helpful: Lune helped. issue: an error or something broken. idea: a suggestion.
`allow_training`	No	True only when the user explicitly agreed that Lune may use this feedback to train its models.

Output Schema

Name	Required	Description	Default
`id`	Yes	The stored feedback's id; nothing to show the user.
`status`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 5, 2026

TDQS

A4.6/5.0

Behavior4/5

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

With annotations covering safety (non-read-only, non-destructive, non-idempotent), the description still adds substantial behavioral context: consent must be obtained, the message must be shown before sending, and the training opt-in requires a separate disclosure that it can be withdrawn in account settings. It doesn't mention duplicate-submission behavior despite idempotentHint=false, which is the one remaining gap.

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?

Purpose is front-loaded in the first clause, followed by usage conditions and then parameter guidance in a logical order. The prose is dense and long-sentenced, but nearly every clause carries an actionable constraint; the privacy guidance is stated twice (description body and message field), which is mild redundancy.

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 three-parameter write tool with an output schema already present, the description covers everything an agent needs: trigger conditions, the consent workflow, the draft-review step, the training opt-in disclosure, and content hygiene. Return values need not be explained because an output schema exists.

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 baseline is 3, but the description adds genuine meaning beyond the schema: it specifies the consent precondition for allow_training (only after telling the user they may withdraw it) and constrains message content to what the user said about Lune, excluding unrelated conversation and personal details. That goes past the schema's own field docs rather than restating them.

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 first sentence names a specific verb and resource ('Sends the user's feedback about Lune to the Lune team') and makes clear this is a feedback channel rather than a research tool, which cleanly separates it from every sibling (search_papers, verify_claims, etc.). An agent can identify the action without opening the 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?

It explicitly states the triggering condition (the user says something about Lune itself, with concrete examples: missed papers, unfitting results, errors, praise, ideas) and the required procedure: offer to pass it on, show the drafted message, and call only after the user agrees. That is an explicit when-to-use plus a hard gate, not inference.

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

All Lune Research 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.