Skip to main content
Glama

Submit Feedback

submit_feedback

Report a problem with ActivitySmith to the ActivitySmith team. Use it when a tool fails in a way you cannot fix, when the user asks for something ActivitySmith cannot do, or when the docs or a tool description sent you the wrong way.

Report a missing capability instead of guessing a workaround. Do not use it for mistakes you can correct yourself, such as invalid input or a missing permission, or to send the user a message; use send_push_notification for that.

Do not include API keys, tokens, or other secrets. Include personal data or notification content only when the report needs it. Tell the user what you reported.

This goes to the ActivitySmith team with the account and agent name. It sends nothing to the user's devices and changes nothing on the account. Sending the same summary again adds to the existing report. Each account can file 10 new reports in 24 hours. Returns feedback_id and already_reported. Continue the user's task afterward.

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": {
      "type": "<type>",
      "summary": "<summary>"
    },
    "name": "submit_feedback"
  }
}

Input Schema

NameRequiredDescriptionDefault
typeYesbug for wrong behavior or an unexpected error. missing_feature for something ActivitySmith cannot do. docs for wrong or unclear docs or tool descriptions. other for anything else.
detailsNoWhat you tried and what happened, including the exact error message. Leave out secrets.
summaryYesOne line that names the problem, such as "Cannot schedule a Push Notification for a later time". Keep it stable across retries so repeats count as one report.
expectedNoWhat you expected to happen, or what the user wanted to do.
tool_nameNoThe ActivitySmith tool involved, such as send_push_notification. Omit when no tool is involved.

Output Schema

NameRequiredDescriptionDefault
messageYes
successYes
feedback_idYes
already_reportedYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the annotations, the description discloses destination and payload (account and agent name go to the ActivitySmith team), side-effect scope (sends nothing to user devices, changes nothing on the account), deduplication behavior (repeating a summary appends to the existing report), a concrete rate limit of 10 new reports per 24 hours, and return fields. These are exactly the traits an agent cannot infer from readOnlyHint/destructiveHint/openWorldHint.

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 and triggers are front-loaded, and the paragraph breaks map to purpose, exclusions, content rules, and side effects. It is on the long side and repeats the privacy caveat that already exists in the details schema field, but nearly every sentence carries an operational constraint.

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 write tool that leaves the account with no external side effects, the description covers audience, exclusions, rate limit, dedup semantics, privacy constraints, and follow-up action (continue the user's task). With an output schema present, no return-value explanation is owed, and the mention of feedback_id and already_reported is a bonus.

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 the baseline would be 3, but the description adds real meaning: the dedup rule tied to the summary field ("Keep it stable across retries" is echoed as "sending the same summary again adds to the existing report") clarifies why summary must be stable. It also gives privacy guidance covering all free-text fields (no API keys or tokens, personal data only when needed) and the instruction to tell the user what was reported.

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 opens with a specific verb and resource: "Report a problem with ActivitySmith to the ActivitySmith team." It is unmistakably distinct from siblings such as send_push_notification, and the audience (the ActivitySmith team, not the user) is stated up front.

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 enumerates three concrete trigger conditions (unfixable tool failure, capability gap, misleading docs), then states explicit exclusions (self-correctable mistakes like invalid input or missing permission) and names the correct alternative, send_push_notification, for user-facing messages. It even advises reporting a missing capability rather than guessing a workaround.

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.

Resources