Skip to main content
Glama
Sign In

WattCoin

by io.github.WattCoin-Org
OverviewDiscussionsAdmin

WattCoin: Install skill

install_skill

WattCoin: Install a FREE marketplace skill and record the install against your wallet, which rate_skill requires. Paid skills are refused. Use get_skill first to check price and permissions. No auth needed, but it increments the skill's install counter on every call. Returns JSON with download_url (public install URL), size_bytes, sha256 and permissions; the ZIP itself is never returned.

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": {
      "skill_id": "<skill_id>",
      "wallet": "<wallet>"
    },
    "name": "install_skill"
  }
}

Input Schema

NameRequiredDescriptionDefault
walletYesSolana wallet address, base58, 32-44 characters (e.g. 7vvNk...). The install is recorded against it, and rate_skill must use the same wallet
skill_idYesSkill ID from browse_marketplace

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.7/5.0
Behavior5/5

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

Beyond the annotations (readOnly=false, idempotent=false), the description discloses that no auth is needed, that every call increments the install counter (a non-idempotent side effect), and that the ZIP is not returned—only metadata. Those are exactly the behavioral facts an agent needs to avoid repeat calls and wrong expectations.

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?

Four tight sentences, front-loaded with the core action and free/paid constraint, then prerequisites, then side effects, then return shape. No sentence is redundant.

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?

There is no output schema, and the description explicitly lists the returned JSON fields (download_url, size_bytes, sha256, permissions) and clarifies the ZIP is never returned. With annotations already covering safety/idempotency, the description leaves no material gap for calling the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so both skill_id and wallet are fully documented in the schema, including the rate_skill wallet-consistency requirement. The description reinforces the wallet recording behavior but adds no new syntax or constraints beyond the schema; baseline 3 is appropriate.

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 states a specific verb and resource ("Install a FREE marketplace skill") and immediately scopes it: free only, paid refused. It also distinguishes the tool from siblings by noting the rate_skill dependency and pointing to get_skill as a prerequisite.

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?

Usage is explicit: call get_skill first to check price/permissions, paid skills are refused, and the install record is required by rate_skill. This gives the agent both the when and the when-not, plus the sibling to consult beforehand.

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

All WattCoin toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources