Skip to main content
Glama

Homespun

by dev.homespun

Publisher Profile

publisher

The caller's community publisher identity: the @-handle and public profile shown in the template gallery. Actions: get returns the profile, including the handle, whether it has been claimed, tenure, and the rating and template counters; claim sets the handle from a lowercase 3-to-32-character string and may be used only once, after which the handle is permanent, and it refuses a handle that is reserved or already taken; update changes display_name, bio or url at any time. claim and update require a verified email. An existing publisher may hold a provisional maker-... handle assigned automatically, which claim renames on its one allowed use.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
bioNoupdate only. Short public bio (up to 500 chars); null clears it.
urlNoupdate only. Public http(s) URL (up to 200 chars); null clears it.
actionYesget: returns the caller's publisher profile (handle, tenure, counters). claim: sets the caller's @-handle, once (handle arg; lowercase, 3 to 32 chars, permanent after claiming; needs a verified email). update: changes the caller's public display_name/bio/url (any of them; needs a verified email).
handleNoclaim only. The lowercase @-handle to claim (^[a-z0-9](?:[a-z0-9-]{1,30}[a-z0-9])$). Permanent once claimed.
display_nameNoupdate only. Public display name (up to 80 chars); null clears it.

TDQS

A4.7/5.0
Behavior5/5

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

Beyond annotations, the description discloses important behaviors: claim is one-time permanent, refuses reserved/taken handles, requires verified email, and explains the provisional `maker-` handle. This is rich behavioral context not available from annotations alone.

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

Conciseness5/5

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

The description is well-structured with actions clearly enumerated in a compact paragraph. It front-loads the core identity concept and each sentence provides necessary information without redundancy.

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?

Given the multi-action nature and lack of output schema, the description thoroughly covers return values for get, behaviors for claim/update, and prerequisites. It is complete enough for an agent to select and invoke correctly.

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?

The schema already describes all parameters with high coverage, but the description adds critical meaning: the handle permanence after claim and the one-time use restriction. This extra context clarifies parameter semantics beyond the schema.

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 clearly defines the tool as managing the caller's publisher identity, with distinct actions (get, claim, update) and specific resources (handle, profile fields). It differentiates from sibling tools like members or community by focusing on the publisher profile.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear context for when to use each action, including prerequisites like verified email for claim/update. It does not explicitly name alternative tools, but the scope is unambiguous and no sibling is a direct substitute.

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