Skip to main content
Glama

Define an achievement

define_achievement

Create or update a game achievement by slug, defining its name, description, points, and badge. Idempotent on game and slug, so re-running a publish script never resets player unlocks.

Instructions

Adds one achievement to a game you own, or overwrites the one that already has this slug. Achievements are maker data: only the owner defines them, and the game itself can never mint one — a build calls Arcade.achievements.unlock("<slug>") and we refuse any slug that is not already defined here. This tool is idempotent on (game, slug), so a publish script can run twice without making a mess, and re-declaring a badge never resets how many players have earned it. Use define_achievements when you are declaring a whole set at once. Max 100 per game.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
gameYesThe game, by slug (e.g. "orbital-drift") or by id (uuid).
nameYesWhat players see on the badge, up to 60 characters. Name the deed, not the mechanic: "Untouchable" beats "damage_taken == 0".
slugYesThe stable key your game code passes to Arcade.achievements.unlock(). Lowercase letters, digits and hyphens, up to 48 characters — e.g. "first-win", "no-damage-run". Pick it once and keep it: renaming the name or description never breaks a shipped build, changing the slug breaks every call site in it.
emojiNoOne emoji, drawn as the badge face. Defaults to 🏆.🏆
hiddenNoSecret until earned. A hidden achievement still shows on the game page as a locked mystery tile with its rarity count, but its name and description are redacted server-side until that player unlocks it. Use it for endings and easter eggs, not for everything.
pointsNoWeight, 0-100, defaults to 10. Spend it like a budget: a whole game worth 10 achievements at 10 points each says everything is equally hard, which is never true.
iconUrlNohttps:// URL of a custom badge image, used instead of the emoji. Optional.
sortOrderNoDisplay position, ascending. Ties fall back to slug order.
descriptionNoHow it is earned, in one plain-text line, up to 240 characters. No markdown. For a hidden achievement this is only revealed once a player unlocks it.
Behavior1/5

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

The description provides rich behavioral context: owner-only maker data, game-code integration with Arcade.achievements.unlock(), idempotency on (game, slug), preservation of earned counts, and a 100-per-game cap. However, it directly contradicts the annotation idempotentHint=false by declaring 'This tool is idempotent on (game, slug)'. Per the scoring rule, a contradiction with annotations forces a score of 1.

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 four purposeful sentences with the core behavior front-loaded, followed by ownership/security context, idempotency, sibling routing, and the hard limit. Every sentence earns its place and there is no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 9-parameter tool with no output schema, the description covers most operational essentials: ownership, game-side code contract, overwrite behavior, idempotent retry safety, batch alternative, and maximum count. It loses a point because the idempotency claim is contradicted by the idempotentHint=false annotation, making the behavioral picture unreliable, and no return-value information is provided.

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 description coverage is 100%, so the input schema already documents all nine parameters, including guidance for slug, name, hidden, points, and description. The tool description adds contextual limits and idempotency, but no per-parameter semantics beyond what the schema already provides, so the baseline 3 applies.

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: 'Adds one achievement to a game you own, or overwrites the one that already has this slug.' It clearly distinguishes this single-achievement upsert from the plural define_achievements tool and from update/delete alternatives.

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?

It explicitly states the ownership precondition, explains when the tool is safe for publish scripts, names the alternative define_achievements for batch declaration, and gives the max-per-game limit. This is actionable routing guidance, not just a vague hint.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/elliothimmelfarb/aimade-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server