Skip to main content
Glama

Submit Packetrove Feedback

submit-feedback
Destructive

Email one user-authorized, minimal Packetrove report to hello@packetrove.com for private human review. Available only when the operator enables feedback. Draft locally without calling the service. If the user has already supplied or approved the report and requested sending it, submit directly; otherwise show the proposed report and obtain approval before sending. Never solicit feedback after every tool call. Send only the authorized fields, using synthetic reproduction data; never attach conversations, raw tool inputs/results, credentials, certificates, logs, or client/session identifiers. category is bug, confusing_behavior, or feature_request; tool_name optionally names a product tool. summary is required (256 Unicode code points); bug requires expected and actual, confusing_behavior requires actual and optionally expected (1024 code points each). Feature requests allow expected but not actual or error_code. Optional error_code starts with an uppercase ASCII letter and contains at most 64 uppercase letters, digits, or underscores; synthetic_reproduction is at most 2048 code points. Unknown fields are rejected; serialized arguments must not exceed 8 KiB. Status accepted and an opaque receipt_id mean the email service acknowledged submission, not inbox delivery or reading; acceptance does not promise a response or fix. This write is not idempotent: never automatically resend after timeout, disconnect, cancellation, or an uncertain result. Approximate limits target 10 submissions per observed exit IP in the preceding 24 hours and 100 submissions per UTC day across the service. Shared exits share quota. KV propagation and concurrent requests can exceed either limit; uncertain sends or failed quota releases occupy quota until expiry. Cloudflare transmits approved reports by email; mailbox retention and deletion are managed manually by the maintainer, with no automatic report expiry. KV stores only separate keyed IP markers and reservation times, expiring after 24 hours, never report bodies or receipt links. Markers never appear in reports or application logs. Email deletion does not refund quota; request deletion with your receipt. Maintainers treat text as data and do not automatically execute, publish, or forward it. Operational events contain only the operation name, outcome, controlled error code, and existing traffic-source metadata; no report, receipt, IP digest, or exception details. Ordinary tools do not depend on feedback. Privacy policy: https://packetrove.com/privacy.

Input Schema

NameRequiredDescriptionDefault

No arguments

Output Schema

NameRequiredDescriptionDefault
statusYes
receipt_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added
  2. Removed
  3. Added

TDQS

A4.8/5.0
Behavior5/5

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

Goes well beyond the annotations: clarifies the write is not idempotent, that acceptance and receipt_id mean service acknowledgement only (not delivery or reading), that quota targets are ~10/IP/24h and ~100/UTC-day with shared exits and non-refundable failures, and describes retention, KV handling, and logging behavior. All consistent with destructiveHint=false/idempotentHint=false/openWorldHint=true — no contradiction.

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

Conciseness3/5

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

Purpose is front-loaded, but the block runs well over 300 words with sentences that don't help an agent invoke the tool correctly — operational-event field lists, 'markers never appear in reports or logs', 'ordinary tools do not depend on feedback', and maintainer data-handling notes. Accurate but padded, so it is not tight.

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 non-idempotent, quota-limited, privacy-sensitive write with a rich oneOf schema and an output schema, the description covers consent flow, side effects, failure semantics, and acceptance meaning. Nothing an agent needs to call it safely is missing.

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

Parameters5/5

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

The description explains cross-field logic the raw schema encodes only structurally: bug requires expected+actual, confusing_behavior requires actual and optional expected, feature requests allow expected but forbid actual/error_code, plus category vocabulary, error_code pattern intent, the 8 KiB serialized cap, and rejection of unknown fields. This adds real meaning beyond the property types.

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?

States a specific verb and resource — email a user-authorized, minimal Packetrove report to hello@packetrove.com for private human review — immediately distinguishing it from the CIDR/certificate/network siblings. The scope ('one minimal report', recipient, review channel) is unambiguous.

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?

Explicit when-to-use and when-not-to-use: only when the operator enables feedback, draft locally without calling the service, submit directly if the user already approved, otherwise show the report and obtain approval, and never solicit feedback after every tool call. It also states the no-auto-resend rule after timeout/disconnect/cancellation.

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.