Skip to main content
Glama

Manage Feedback

feedback

Reports a problem with homespun itself to the relay operator, and lists what this agent has already reported. A report is the operator's only visibility into a failure that happened inside an agent's session, so an unreported one is a failure nobody can fix.

The channel covers homespun's own behaviour: a 5xx, or an error code the guide does not describe; a disagreement between documented and observed behaviour; something the tool surface cannot express, such as a missing capability or a schema that contradicts itself; an app misbehaving in a way that traces back to the platform (the bridge, the runtime, serving, the data API) rather than to authored HTML; or a guide that was wrong, ambiguous or silent.

Outside its scope: the human's own task; bugs in an app the agent authored; presentation preferences, which belong in taste; the human's own configuration, such as a missing API key or the wrong account; and a 4xx caused by the agent's own arguments, except where the error message itself was misleading, which is a documentation problem best filed as a note.

Duplicates cost the operator triage rather than adding signal. Action list returns this agent's own submissions, newest first, so a failure already recorded needs no second row: one report covers one distinct failure, however many times it was retried.

The operator sees the row and not the session, so a bare "deploy failed" is not actionable. An actionable message carries the surface (mcp, cli, relay or app-runtime); where it happened (the tool or route); the skill version, from the <!-- homespun skill vX.Y.Z --> comment at the top of the guide; what was expected, in one line; what was observed, in one line carrying the exact error code and message; and the minimal steps or arguments that reproduce it.

type is bug for something broken, feature for something missing, note for a rough edge or a confusing doc. app_id scopes a report to one app. There is no reply channel, so a report is not a route to an answer. Actions: create files one report; list returns this agent's own submissions, newest first, paginated by before.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
typeNoFeedback category (required for create).
limitNolist page size (default 50, max 100).
actionYesReports a problem with homespun itself to the relay operator. create: files one bug|feature|note with a message and an optional app_id. list: this agent's own submissions, newest first, which is what distinguishes a new failure from one already reported.
app_idNoOptional app this feedback relates to (create).
beforeNolist cursor from a prior page's next_before.
messageNoMessage body (required for create).

TDQS

A4.8/5.0
Behavior5/5

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

With all annotations false, the description carries the full burden. It discloses that the operator sees the row, not the session, that there is no reply channel, that duplicates cost triage, and gives detailed requirements for an actionable message. This goes beyond the schema.

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?

The description is long but information-dense, with no fluff. Each paragraph adds unique value: scope boundaries, duplicate policy, message composition, and parameter semantics. The main purpose is front-loaded in the first sentence.

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?

Despite no output schema, the description covers return behavior (list newest first, paginated by `before`), all param semantics, and operational expectations (no reply channel, duplicate handling). It is comprehensive for a reporting tool with moderate complexity.

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 enriches parameters: it defines each `type` enum ('bug for something broken, feature for something missing, note for a rough edge'), explains `app_id` scopes to one app, and `before` as pagination cursor. It also clarifies the `action` parameter's effects.

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 explicitly states the tool 'Reports a problem with homespun itself to the relay operator, and lists what this agent has already reported,' naming the resource (homespun problems) and actions (create/list). This distinguishes it from sibling tools like `taste` or `deploy_app` by scope.

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?

The description provides explicit scope: it lists what is in scope (5xx, error codes, disagreements, platform issues) and out of scope (human's task, authored app bugs, presentation preferences – which it says belong in `taste`). It also instructs to use `list` to check duplicates before creating a report.

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.

TDQS

A4.4/5.0
Disambiguation5/5

Each tool targets a distinct resource or action: row operations (get/list/upsert/update/delete/restore) are clearly separated, while apps, attachments, community, grants, ingest, members, publisher, review, and taste each cover a different domain. Even closely related actions like share_link_rotate and domain_set have clearly scoped descriptions, so an agent can reliably select the right tool.

Naming Consistency4/5

Tool names use two patterns: noun-like names for resource areas (apps, attachments, community, grants, ingest, members) and verb_noun names for row operations (upsert_row, delete_row, etc.). This deviation is predictable and readable, but it is not perfectly uniform, so a slight deduction applies.

Tool Count4/5

With 22 tools, the server is on the heavier side, but the breadth of the platform (app lifecycle, data storage, attachments, community, reviews, feedback, identity) justifies the count. Each tool represents a meaningful feature area with multiple internal actions, so none feels redundant.

Completeness5/5

The tool surface covers the full lifecycle for apps (create, read, update, delete), rows (create, read, update, delete, restore, list deleted), attachments, membership, grants, ingest, community, and reviews. Obvious gaps like rollback or version history are not core to the domain, and the presence of get_skill helps agents understand the workflow.

Resources