Skip to main content
Glama

Homespun

by dev.homespun

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.9/5.0
Behavior5/5

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

Goes well beyond the sparse annotations by disclosing that there is no reply channel, that list returns only the agent's own submissions, and that an unreported failure is invisible to the operator. Also explains duplicate handling and action details, making behavioral expectations clear.

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 lengthy but every paragraph serves a purpose: scope, exclusions, duplicate warning, actionable message structure, and type semantics. It is front-loaded with the core purpose and well-paragraphed, though slightly dense for a fast scan.

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 tool with two actions, six parameters, and nuanced scope, the description covers all necessary context: purpose, usage boundaries, duplicate handling, message composition, type meanings, app_id, lack of reply channel, and pagination. There is no output schema, but the description explains what list returns and how paging works.

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?

Although the schema has 100% coverage, the description enriches each parameter with practical meaning: type definitions (bug/feature/note), app_id scoping, message actionability requirements (surface, location, expected vs. observed, reproduction steps), and pagination via `before`. This goes far beyond the schema's bare descriptions.

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: 'Reports a problem with homespun itself to the relay operator, and lists what this agent has already reported.' This clearly distinguishes feedback from sibling tools like taste or review by scoping it to platform-level issues.

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?

Provides explicit in-scope and out-of-scope guidance, naming alternatives (e.g., presentation preferences belong in `taste`, documentation issues best filed as a `note`). Also clarifies when to use list vs. create and warns that duplicates are counterproductive.

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

All Homespun toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.1/5.0
Disambiguation4/5

Most tools are clearly distinct, with row operations (list, get, upsert, update, delete, restore) well separated. Some boundaries like apps vs deploy_app and credentials vs grants require careful reading, but descriptions resolve the overlap.

Naming Consistency2/5

Tool names mix resource nouns (apps, attachments, connections) with verb_noun actions (delete_row, deploy_app). Singular and plural forms are inconsistent, and there is no uniform pattern across the set.

Tool Count3/5

24 tools is on the heavy side, but the platform's breadth (app deployment, data, auth, community) justifies the count. Each tool has a distinct role, though the set slightly exceeds the typical well-scoped range.

Completeness4/5

The surface covers the full app lifecycle: deploy, manage, delete, row CRUD with restore, attachments, credentials, and community features. Minor gaps like no dedicated row search or outbound webhook management are workable via existing tools.

Resources