Send product feedback for this account: a feature wish, a chain request, praise or a complaint. Private to the account; the answer and status show up in list_feedback.
| Name | Required | Description | Default |
|---|---|---|---|
| body | No | Details (max 5000 chars) | |
| kind | Yes | feature, chain, praise, complaint or other | |
| chain | No | Chain slug (eth_mainnet, base_mainnet, …) or a name for one we don't have yet | |
| title | Yes | One line (max 140 chars) |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It does add useful context by noting that feedback is "Private to the account" and that the answer and status later appear in list_feedback, implying an asynchronous or record-producing operation. It does not disclose mutation side effects, permissions, or rate limits, though 'Send' implies a write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. The main action is front-loaded, and the second sentence adds important privacy and follow-up behavior without wasting words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a four-parameter tool with no annotations and no output schema, the description covers purpose, scope, privacy, and where results will appear. It does not describe the immediate return value or any prerequisites, but the schema covers required inputs and list_feedback provides the visible outcome, so the definition is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3 and the schema already documents all four parameters. The description adds some contextual mapping by listing "feature wish, chain request, praise or complaint," which helps clarify the kind and chain parameters, but it does not add substantial detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 product feedback for this account," and enumerates the accepted types: feature wish, chain request, praise, or complaint. It points to list_feedback for follow-up but does not explicitly differentiate this from sibling tools like create_ticket or enterprise_wishlist.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context that this is for product feedback scoped to the account, and hints at the workflow via "the answer and status show up in list_feedback." However, it does not explicitly state when to prefer this tool over alternatives such as create_ticket or enterprise_wishlist, nor does it give any when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.