Kellian

Creator agent deletes one of its own canvas updates

kellian_delete_canvas_update

Destructive

Delete one of your own persistent canvas updates from a market you created. Authority is the market creator wallet (ownership-governed, no scope needed); only updates posted by that same wallet can be deleted.

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": {
      "chainId": "<chainId>",
      "marketAddress": "<marketAddress>",
      "walletAddress": "<walletAddress>",
      "id": "<id>",
      "idempotencyKey": "<idempotencyKey>"
    },
    "name": "kellian_delete_canvas_update"
  }
}

Input Schema

Name	Required	Description
`id`	Yes	Canvas update id (UUID) to delete
`chainId`	Yes	Chain ID for the market
`proofNonce`	No	Required single-use nonce for the wallet proof. Fetch from POST /api/auth/nonce; consumed on verification so the proof cannot be replayed.
`marketAddress`	Yes
`walletAddress`	Yes	Wallet address of the caller (must be market creator)
`idempotencyKey`	Yes	Stable retry key. Reuse only with byte-equivalent tool arguments.
`walletSignature`	No	Action-bound wallet proof. Sign the canonical 'problee-mcp-auth:…' challenge (binds agent, apiKey, tool, scope, chain, resource, payloadHash, nonce, timestamp).
`signatureTimestamp`	No	Unix timestamp (seconds) used in the signed challenge message

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 5, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the description's added value is the authorization model: authority derives from the market-creator wallet, no separate scope is needed, and cross-wallet updates are out of bounds. It does not discuss whether deletion is permanent or reversible, nor what happens on an ownership mismatch, which is the main remaining behavioral gap for a destructive operation.

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?

Two tight sentences with zero filler. The operation and its scope lead, and the authorization constraint follows, so the most decision-relevant information is front-loaded.

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 an eight-parameter, five-required destructive tool with a wallet-proof flow, the description covers the ownership/authority dimension that the schema cannot express, and the schema plus output schema carry the parameter and return-value burden. It is slightly incomplete in not mentioning that a signed proof and single-use nonce are prerequisites, and it leaves the intent behind idempotencyKey on a non-idempotent operation unexplained.

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 88%, so the schema already documents id, proofNonce, walletSignature, signatureTimestamp, and idempotencyKey in detail. The description only implicitly ties walletAddress to the market-creator requirement; it adds no format, unit, or constraint information beyond what the schema 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?

States a specific verb (delete), a specific resource (canvas update), and a precise scope ('one of your own persistent canvas updates from a market you created'). The verb alone distinguishes it from kellian_post_canvas_update and kellian_list_canvas_updates in the sibling set without needing to name them.

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?

Gives a clear eligibility rule for use ('only updates posted by that same wallet can be deleted') and the authority model, so an agent knows when this call will succeed. It stops short of explicitly routing to kellian_list_canvas_updates to obtain the target id or stating that the market creator role must be verified first, so no explicit alternative is named.

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

All Kellian tools Inspect

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

Need Help?