Skip to main content
Glama
Sign In
snowluma-file-sender

snowluma-file-sender

by ktouch10
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

send_file

Destructive

Deliver a prepared file to a preconfigured QQ recipient by passing only the deliveryId, while preventing automatic resends for unknown, sending, or busy states.

Instructions

按用户指令发送已准备文件，只传 deliveryId。unknown/sending/busy 禁止自动重发。

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": {
      "deliveryId": "<deliveryId>"
    },
    "name": "send_file"
  }
}

Input Schema

NameRequiredDescriptionDefault
deliveryIdYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.5/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true and openWorldHint=true, so the real-world irreversibility profile is covered. The description adds genuinely non-obvious context beyond that: the single deliveryId payload contract and the idempotency guard forbidding auto-resend while status is unknown/sending/busy. It falls short of explaining success/failure outcomes or what to do when blocked.

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?

Two tight clauses with zero waste, and the blocking rule is front-loaded right after the core action. Nothing to trim.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive, open-world send with no output schema, the description should say where deliveryId comes from and what to do when the state check blocks the send. It covers the resend prohibition but leaves output/result behavior entirely undocumented.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% and the type/format (uuid, pattern) is the only machine-readable hint. '只传 deliveryId' merely restates the single-param contract; it never says what a deliveryId is or that it originates from prepare_file, which is the key semantic an agent needs.

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 specific verb and resource ('发送已准备文件' – send already-prepared file) and constrains the payload to deliveryId. It implicitly excludes prepare_file (this sends files that are '已准备'), but it doesn't name delivery_status or the other siblings explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

'按用户指令发送' hints at when this is used (user-directed sends), and the 'unknown/sending/busy 禁止自动重发' rule gives a concrete when-not-to-act condition. However, it never names the visible alternative – checking delivery_status first – so an agent has to infer where those states come from.

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

Deploy Server

Other Tools