Skip to main content
Glama
Sign In

Arkham

by com.arkm
OverviewDiscussionsAdmin

PostLabels

Destructive

Create labels

Creates or updates labels for the authenticated user. Requires both labels.write and labels.create, including when all labels already exist. To edit existing labels with labels.write alone, use PATCH /user/labels.

Each user has at most one label per address and chain type. Posting a label for an address that already has one replaces it: both name and note are overwritten with the values in the request, so omitting note clears any note already stored.

Addresses are normalized before storage — EVM addresses are checksummed, for example — so the same address written in different letter cases resolves to a single label rather than two.

Costs 0 API credits per call. Modifies Arkham data; confirm the requested change before calling.

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": {
      "body": "<body>"
    },
    "name": "PostLabels"
  }
}

Input Schema

NameRequiredDescriptionDefault
bodyYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.3/5.0
Behavior3/5

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

Annotations already carry the safety profile (destructiveHint=true, readOnlyHint=false), so the description's main value-add is the replace semantics: overwriting name and note, and that omitting note clears an existing note — genuinely useful and beyond the annotations. It also discloses zero API credit cost and address normalization. Gaps: the body is an array but the description never addresses batch behavior (atomicity, partial failure, max entries), and 'replaces existing label' sits in mild tension with idempotentHint=false.

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?

Front-loaded with the action, then permissions, then replace semantics, then normalization and cost — a sensible priority order with little waste. The 'including when all labels already exist' clause is slightly awkward but carries real permission information, so it earns its place.

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 destructive single-parameter mutation with no output schema, the description covers permissions, replace/clear semantics, normalization, cost, and a confirmation nudge — nearly everything needed to call it safely. The remaining hole is the array-shaped body: whether multiple labels can be posted in one call and how partial failures behave is unstated.

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 description coverage is 0%, so the description must compensate, and it does well: it explains name/note overwrite behavior, note omission clearing, the one-label-per-address-plus-chain-type constraint, and address case normalization. chainType is only obliquely hinted at ('chain type') with no allowed values, so one field remains under-specified.

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?

States a specific verb (create/upsert) and resource (labels for the authenticated user), and explicitly contrasts with the sibling PATCH /user/labels path. An agent can distinguish PostLabels from PatchLabels and DeleteUserLabel without reading either schema.

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?

Names the required permission pair (labels.write AND labels.create) including the non-obvious caveat that it still applies when all labels already exist, and routes to the explicit alternative when only labels.write is held. Explicit when-to-use and when-to-use-something-else.

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

All Arkham 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