Skip to main content
Glama
schenkty

Keeta Network MCP Server

by schenkty
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Remote

Keeta Network MCP Server

A dynamic, self-describing MCP (Model Context Protocol) server that gives AI agents native access to the Keeta Network — a Layer 1 blockchain built for payments, asset transfers, cross-chain interoperability, and compliance-ready financial infrastructure.

This server is designed for autonomous agent use. It does not require updates when the Keeta SDK is expanded — new SDK methods are automatically discoverable at runtime through built-in introspection tools.

What is Keeta Network?

Keeta is a Layer 1 blockchain purpose-built for the global financial system:

  • 10M+ TPS with 400ms settlement — faster than any traditional payment rail

  • Native tokenization — create tokens with built-in rules (transfer restrictions, allowlists, time locks) enforced at protocol level

  • Atomic swaps — instant exchange between any two assets on the network

  • Anchors — regulated entry/exit points that bridge Keeta to external systems (SWIFT, ACH, FedNow, other blockchains like Base/Ethereum). Any foreign asset tokenized on Keeta is 1:1 backed and can be returned to its native chain at any time

  • Built-in compliance — X.509 certificate-based identity for KYC/AML without storing PII on-chain

  • Permissions system — granular per-account and per-token access controls (ACCESS, ADMIN, SEND, RECEIVE, etc.)

  • DAG architecture — each account has its own chain, enabling parallel transaction processing

  • Multiple signature algorithms — ECDSA SECP256K1, SECP256R1 (WebAuthn), ED25519

Token: KTA (used for transaction fees and governance) Networks: main (production), test (development with free faucet)

Related MCP server: Armor Crypto MCP

Quick Start

Install

git clone <this-repo>
cd kta-mcp
npm install
npm run build

Configure (Recommended: Both MCP Servers)

Agents building on Keeta should use two MCP servers together:

  1. keeta-docs — The Keeta documentation MCP (hosted by GitBook) provides searchable protocol knowledge: architecture, anchor system, SDK references, tutorials

  2. keeta-sdk — This server provides the tools to execute operations on the network

Claude Code

# Add the Keeta docs MCP (read the docs, understand the protocol)
claude mcp add --transport http keeta-docs https://docs.keeta.com/~gitbook/mcp

# Add the Keeta SDK MCP (execute operations on the network)
claude mcp add keeta-sdk node /absolute/path/to/kta-mcp/build/index.js

Claude Desktop / Other MCP Clients

{
  "mcpServers": {
    "keeta-docs": {
      "type": "url",
      "url": "https://docs.keeta.com/~gitbook/mcp"
    },
    "keeta-sdk": {
      "command": "node",
      "args": ["/absolute/path/to/kta-mcp/build/index.js"]
    }
  }
}

Why both? The docs MCP gives agents the knowledge to build correctly (protocol rules, anchor architecture, metadata formats, compliance requirements). The SDK MCP gives agents the tools to execute. Using only the SDK server without understanding the protocol is like having a hammer without knowing what you're building.

Development

npm run dev    # Run with tsx (no build step)
npm run build  # Compile TypeScript
npm start      # Run compiled output

Architecture: Dynamic & Future-Proof

This MCP server uses a discover-then-execute pattern instead of hardcoded tools. When the Keeta SDK adds new methods, classes, or features, agents discover them automatically without any server updates.

9 Tools — Organized in 3 Layers

┌─────────────────────────────────────────────────────────────────────┐
│  BOOTSTRAP TOOLS (entry points)                                     │
│  keeta_generate_seed         → create a cryptographic seed          │
│  keeta_derive_account        → derive account from seed + index     │
│  keeta_request_test_tokens   → fund an account on testnet           │
│  keeta_get_network_config    → get network ID, base token, etc.     │
├─────────────────────────────────────────────────────────────────────┤
│  DISCOVERY TOOL (runtime introspection)                              │
│  keeta_list_sdk_methods      → introspect any SDK object:           │
│    "AnchorCatalog"           → auto-discover ALL anchor services    │
│    "AnchorService:<Name>"    → drill into any service by name       │
│    "AnchorLib:<Name>"        → drill into any lib module by name    │
│    "Client/UserClient/..."   → core SDK introspection               │
├─────────────────────────────────────────────────────────────────────┤
│  EXECUTION TOOLS (generic, call any SDK method by name)             │
│  keeta_client_execute        → read-only network queries            │
│  keeta_user_client_execute   → authenticated account operations     │
│  keeta_builder_execute       → batch operations → publish           │
│  keeta_anchor_execute        → ANY anchor service or lib module     │
│    subtarget: "service"      → dynamic: FX, KYC, AssetMovement...  │
│    subtarget: "lib"          → dynamic: Resolver, Certificates...   │
│    subtarget: "metadata"     → Resolver.Metadata shortcuts          │
└─────────────────────────────────────────────────────────────────────┘

Smart Argument Resolution

Arguments passed to execution tools are automatically resolved based on prefixes:

Pattern

Resolves To

Example

keeta_abc123...

Account.fromPublicKeyString(...)

Token/account addresses

BIGINT:50000

BigInt(50000)

Token amounts, supplies

PERM:ACCESS,ADMIN

new Permissions(['ACCESS','ADMIN'])

Permission sets

ALGO:TOKEN

AccountKeyAlgorithm.TOKEN

Key algorithm enums

ADJUST:SET

AdjustMethod.SET

Permission adjustment methods

OP:SEND

OperationType.SEND

Block operation types

BUFFER_B64:aGVsbG8=

Buffer.from('aGVsbG8=','base64')

Binary data

Plain values

Pass through unchanged

Strings, numbers, booleans, objects

Agent Workflow Guide

This section describes the recommended workflow for an AI agent using this MCP server. Follow these patterns for any Keeta operation.

Step 0: Read the Documentation (keeta-docs MCP)

Before writing any code, use the Keeta docs MCP server to understand the protocol:

# Via the keeta-docs MCP server (https://docs.keeta.com/~gitbook/mcp):
# - Search for "anchors" to understand the anchor system
# - Search for "block operations" to understand transaction types
# - Search for "permissions" to understand access control
# - Search for "certificates" to understand KYC/identity
# - Search for "tokenization" to understand native token creation

The docs MCP provides full access to https://docs.keeta.com/ — architecture guides, anchor system documentation, SDK references, and tutorials. This is essential context for building anything beyond basic transfers.

You can also read the keeta://docs/mcp-config resource from this server for setup details and key documentation links.

Step 1: Discover What's Available

Introspect the SDK to understand current capabilities:

keeta_list_sdk_methods({ target: "AnchorCatalog" }) → all anchor services & lib modules
keeta_list_sdk_methods({ target: "Client" })        → read-only methods
keeta_list_sdk_methods({ target: "UserClient" })     → authenticated methods
keeta_list_sdk_methods({ target: "Builder" })        → builder/batch methods
keeta_list_sdk_methods({ target: "Account" })        → account utilities + enums
keeta_list_sdk_methods({ target: "Block" })          → block types + operation types
keeta_list_sdk_methods({ target: "Config" })         → network configuration

Step 2: Create an Account

keeta_generate_seed()
→ { seed: "A1B2C3..." }

keeta_derive_account({ seed: "A1B2C3...", index: 0 })
→ { address: "keeta_abc123...", algorithm: "SECP256K1", index: 0 }

Step 3: Fund It (testnet)

keeta_request_test_tokens({ address: "keeta_abc123..." })
→ { status: "success", currentBalance: "5000000000000000000" }

Step 4: Perform Operations

Read-only queries (no account needed):

keeta_client_execute({
  network: "test",
  method: "getAccountInfo",
  args: ["keeta_abc123..."]
})

keeta_client_execute({
  network: "test",
  method: "getAllBalances",
  args: ["keeta_abc123..."]
})

Authenticated operations:

keeta_user_client_execute({
  network: "test",
  seed: "A1B2C3...",
  accountIndex: 0,
  method: "allBalances",
  args: []
})

keeta_user_client_execute({
  network: "test",
  seed: "A1B2C3...",
  method: "generateIdentifier",
  args: ["ALGO:TOKEN"]
})

Read UserClient properties:

keeta_user_client_execute({
  network: "test",
  method: "GET_PROPERTY",
  args: ["baseToken"]
})

Step 5: Batch Operations with Builder

The builder pattern is the most powerful way to perform multiple operations atomically:

keeta_builder_execute({
  network: "test",
  seed: "A1B2C3...",
  accountIndex: 0,
  operations: [
    {
      "method": "setInfo",
      "args": [{
        "name": "USDT",
        "description": "Tether USD on Keeta",
        "metadata": "eyJkZWNpbWFsUGxhY2VzIjo2fQ==",
        "defaultPermission": "PERM:ACCESS"
      }],
      "options": { "account": "keeta_token_address..." }
    },
    {
      "method": "modifyTokenSupply",
      "args": ["BIGINT:1000000000000"],
      "options": { "account": "keeta_token_address..." },
      "computeAfter": true
    },
    {
      "method": "send",
      "args": ["keeta_recipient...", "BIGINT:500000000", "keeta_token_address..."]
    }
  ],
  autoPublish: true
})

Key builder details:

  • computeAfter: true forces block computation after that operation (important when later operations depend on earlier ones, e.g., minting supply before sending tokens)

  • options is passed as the final argument — commonly { account: "keeta_..." } to target a specific token/identifier

  • autoPublish: true (default) calls computeBlocks() and publish() after all operations

Common Task Recipes

Create a Token

1. keeta_generate_seed() → seed
2. keeta_derive_account({ seed, index: 0 }) → ownerAddress
3. keeta_request_test_tokens({ address: ownerAddress })
4. keeta_user_client_execute({ network: "test", seed, method: "generateIdentifier", args: ["ALGO:TOKEN"] }) → tokenAddress
5. keeta_builder_execute({
     network: "test", seed,
     operations: [
       { method: "setInfo", args: [{ name: "MYTKN", description: "My Token", metadata: "<base64 of {decimalPlaces:6}>", defaultPermission: "PERM:ACCESS" }], options: { account: tokenAddress } },
       { method: "modifyTokenSupply", args: ["BIGINT:1000000000000"], options: { account: tokenAddress }, computeAfter: true },
       { method: "send", args: [ownerAddress, "BIGINT:100000000", tokenAddress] }
     ]
   })

Send Tokens

keeta_builder_execute({
  network: "test", seed,
  operations: [
    { method: "send", args: ["keeta_recipient...", "BIGINT:1000000", "keeta_token..."] }
  ]
})

Atomic Swap

keeta_user_client_execute({
  network: "test", seed,
  method: "createSwapRequest",
  args: [{
    from: { account: "keeta_sender...", token: "keeta_tokenA...", amount: "BIGINT:1000" },
    to: { account: "keeta_counterparty...", token: "keeta_tokenB...", amount: "BIGINT:500" }
  }]
})

FX Swap via Anchor

1. keeta_anchor_execute({ network: "test", subtarget: "service", serviceName: "FX", method: "getQuotes", args: [{ from: "keeta_kta...", to: "$USDC", amount: "BIGINT:1000000", affinity: "from" }] })
2. Use returned quote to execute the exchange

Update Permissions

keeta_user_client_execute({
  network: "test", seed,
  method: "updatePermissions",
  args: ["keeta_principal...", "PERM:ADMIN,ACCESS", null, "ADJUST:SET"],
  // optional: pass { account: "keeta_target..." } to target a specific token
})

Resolve Anchor Metadata

keeta_anchor_execute({
  network: "test",
  subtarget: "lib",
  libModule: "Resolver",
  method: "getRootMetadata",
  args: []
})

KYC Identity Verification

// Discover KYC methods first
keeta_list_sdk_methods({ target: "AnchorKYCClient" })

// Start a KYC verification request
keeta_anchor_execute({
  network: "test", seed, subtarget: "service", serviceName: "KYC",
  method: "createVerification",
  args: [{ account: "keeta_user...", countryCodes: ["US"] }]
})

// Get supported countries
keeta_anchor_execute({ network: "test", subtarget: "service", serviceName: "KYC", method: "getSupportedCountries", args: [] })

Cross-Chain Asset Movement

// Find providers for a specific asset transfer
keeta_anchor_execute({
  network: "test", seed, subtarget: "service", serviceName: "AssetMovement",
  method: "getProvidersForTransfer",
  args: [{ asset: { token: "keeta_usdc..." }, from: { location: "keeta" }, to: { location: "base" } }]
})

// Provider methods (after getting a provider): initiateTransfer, getTransferStatus,
// createPersistentForwardingAddress, listForwardingAddresses, listTransactions, shareKYCAttributes

Username Management

// Resolve a username to an account
keeta_anchor_execute({
  network: "test", subtarget: "service", serviceName: "Username",
  method: "resolve",
  args: ["alice@provider"]
})

// Search usernames
keeta_anchor_execute({
  network: "test", subtarget: "service", serviceName: "Username",
  method: "search",
  args: [{ search: "alice" }]
})

// Claim a username (requires funded account)
keeta_anchor_execute({
  network: "test", seed, subtarget: "service", serviceName: "Username",
  method: "claimUsername",
  args: ["alice@provider", { account: "keeta_user..." }]
})

Push Notifications

// Get notification providers
keeta_anchor_execute({
  network: "test", subtarget: "service", serviceName: "Notification",
  method: "getProviders",
  args: []
})
// Provider methods: registerTarget, listTargets, deleteTarget,
// createSubscription, listSubscriptions, deleteSubscription

Encrypted Containers & Certificates

// Create an encrypted container for sensitive data
keeta_anchor_execute({
  network: "test", subtarget: "lib", libModule: "EncryptedContainer",
  method: "fromPlaintext",
  args: ["BUFFER_B64:aGVsbG8gd29ybGQ="]
})

// Parse a Keeta URI
keeta_anchor_execute({
  network: "test", subtarget: "lib", libModule: "URI",
  method: "parseKeetaURI",
  args: ["keeta://..."]
})

Building an Anchor (Agent Guide)

An anchor bridges the Keeta blockchain to an external system (another blockchain, a bank, a payment processor). Here's how an agent can build one:

What an Anchor Does

  1. Holds liquidity — the anchor operator's account holds tokens on both sides

  2. Provides FX quotes — tells users what exchange rate they'll get

  3. Executes atomic swaps — uses Keeta's native swap mechanism to guarantee both sides complete

  4. Exposes HTTP endpoints — getEstimate, getQuote, createExchange, getExchangeStatus

Anchor Architecture

External System (e.g., Base chain)
        ↕ (bridge logic you build)
Anchor FX HTTP Server
  ├── /api/getEstimate        → estimate conversion rate
  ├── /api/getQuote           → firm quote with provider signature
  ├── /api/createExchange     → execute the swap atomically
  └── /api/getExchangeStatus  → check swap status
        ↕ (Keeta SDK)
Keeta Network (native atomic swaps)

Steps to Build an Anchor

  1. Create anchor operator account — generate seed, derive account, fund it

  2. Create or identify token pairs — the tokens being swapped (e.g., KTA ↔ USDC)

  3. Fund liquidity — ensure the operator account holds enough of both tokens

  4. Build an FX HTTP server — use @keetanetwork/anchor SDK's KeetaNetFXAnchorHTTPServer class, providing your getConversionRateAndFee callback

  5. Register anchor metadata — publish on-chain metadata with setInfo() including the currency map and FX service endpoints

  6. Test — use the FX client tools to get quotes and execute swaps against your anchor

Registering Anchor Metadata On-Chain

keeta_user_client_execute({
  network: "test", seed,
  method: "setInfo",
  args: [{
    name: "MY_ANCHOR",
    description: "My Custom FX Anchor",
    metadata: "<use keeta_anchor_execute with subtarget 'metadata', method 'formatMetadata'>"
  }]
})

The metadata includes:

  • currencyMap — maps human-readable codes ($KTA, $USDC) to token addresses

  • services.fx.<ProviderName> — defines available conversion pairs and API endpoint URLs

Format Anchor Metadata

keeta_anchor_execute({
  network: "test",
  subtarget: "metadata",
  method: "formatMetadata",
  args: [{
    version: 1,
    currencyMap: { "$KTA": "keeta_kta...", "$USDC": "keeta_usdc..." },
    services: {
      fx: {
        MyProvider: {
          from: [{ currencyCodes: ["keeta_kta..."], to: ["keeta_usdc..."] }],
          operations: {
            getEstimate: "https://my-anchor.com/api/getEstimate",
            getQuote: "https://my-anchor.com/api/getQuote",
            createExchange: "https://my-anchor.com/api/createExchange",
            getExchangeStatus: "https://my-anchor.com/api/getExchangeStatus/{exchangeID}"
          }
        }
      }
    }
  }]
})

SDK Discovery Targets

Core SDK

Target

What It Exposes

When To Use

Client

Read-only methods: getAccountInfo, getBalance, getAllBalances, getHeadBlock, getBlock, getHistory, getTokenSupply, getNetworkStatus, getPeers, getVersion, getLedgerChecksum, getAllCertificates, getAllRepresentativeInfo

Querying the network without an account

UserClient

All Client methods plus: send, setInfo, generateIdentifier, allBalances, balance, head, chain, history, state, updatePermissions, createSwapRequest, transmit, listACLsByPrincipal, getCertificates, modifyCertificate, sync

Any operation requiring an account

Builder

Batch operations: send, receive, setInfo, modifyTokenSupply, modifyTokenBalance, computeBlocks, publish

Multi-step operations that should execute atomically

Account

Static utilities: fromSeed, fromPublicKeyString, generateRandomSeed, generateNetworkAddress, seedFromPassphrase, isIdentifierKeyType + AccountKeyAlgorithm enum

Account creation and key management

Block

Block construction: Builder, OperationType enum, AdjustMethod enum, NO_PREVIOUS

Low-level block building

Permissions

Permission construction methods

Access control

Config

getDefaultConfig

Network configuration

Anchor SDK (Fully Dynamic)

Anchor services and lib modules are not hardcoded — they are auto-discovered from SDK exports at runtime. When the SDK adds new services, they appear automatically.

Discovery flow:

keeta_list_sdk_methods({ target: "AnchorCatalog" })
  → lists all services and lib modules with their methods

keeta_list_sdk_methods({ target: "AnchorService:FX" })
  → drill into a specific service

keeta_list_sdk_methods({ target: "AnchorLib:Resolver" })
  → drill into a specific lib module

Execution flow:

keeta_anchor_execute({
  subtarget: "service",
  serviceName: "FX",        ← any service name from the catalog
  method: "getQuotes",
  args: [...]
})

keeta_anchor_execute({
  subtarget: "lib",
  libModule: "Resolver",    ← any lib module from the catalog
  method: "getRootMetadata",
  args: []
})

Currently discovered services (as of anchor SDK v0.0.49):

Service

Methods

Purpose

FX

getQuotes, getEstimates, getPrices, listPossibleConversions, etc.

Foreign exchange and token swaps

KYC

createVerification, getCertificates, getSupportedCountries

Identity verification

AssetMovement

getProvidersForTransfer, getProviderByID → provider: initiateTransfer, createPersistentForwardingAddress, listTransactions, shareKYCAttributes

Cross-chain/cross-rail transfers

Username

resolve, resolveMulti, claimUsername, search, signUsernameTransfer

On-chain usernames

Notification

getProviders, getProvider → provider: registerTarget, createSubscription, listSubscriptions

Push notifications

Currently discovered lib modules:

Module

Type

Key Members

Resolver

class

getRootMetadata, lookup, listTokens, listTransferableAssets, clearCache, Metadata (static)

Certificates

namespace

Certificate, CertificateBuilder, SensitiveAttribute, SharableCertificateAttributes

EncryptedContainer

class

fromPlaintext, fromEncryptedBuffer, grantAccess, revokeAccess, getPlaintext, verifySignature

URI

namespace

parseKeetaURI, encodeKeetaURI, assertKeetaURIString

Future services and modules will auto-appear in the catalog without MCP server changes.

Project Structure

kta-mcp/
├── package.json              # Dependencies: @keetanetwork/keetanet-client, @keetanetwork/anchor, @modelcontextprotocol/sdk
├── tsconfig.json             # TypeScript ES2022 + Node16 modules
├── src/
│   ├── index.ts              # MCP server entry point (stdio transport)
│   └── tools/
│       ├── helpers.ts        # SDK wrappers, argument resolution, introspection, serialization
│       ├── bootstrap.ts      # Essential tools: seed gen, account derivation, faucet, network config
│       ├── discovery.ts      # keeta_list_sdk_methods — runtime SDK introspection
│       └── execute.ts        # Generic execution: client, user_client, builder, anchor
└── build/                    # Compiled JavaScript output

Dependencies

Resources

License

MIT

Available Tools

9 tools
keeta_anchor_executeA

Execute ANY anchor operation on the Keeta Network. Fully dynamic — auto-discovers services and lib modules from the SDK at runtime.

subtarget types:

  • "service" → call a method on any anchor service client (FX, KYC, AssetMovement, Username, Notification, or ANY future service). Set serviceName to the service name.

  • "lib" → call a method/function on any anchor lib module (Resolver, Certificates, EncryptedContainer, URI, or ANY future module). Set libModule to the module name.

  • "metadata" → shortcut to call Resolver.Metadata static methods (formatMetadata, fullyResolveValuizable)

Use keeta_list_sdk_methods with target "AnchorCatalog" to discover all available services and lib modules. Use "AnchorService:" or "AnchorLib:" to drill into specific ones.

Arguments are auto-resolved (see keeta_client_execute for resolution rules).

ParametersJSON Schema
NameRequiredDescriptionDefault
networkYesNetwork to use
seedNoSeed of the account. Omit for read-only operations.
accountIndexNoAccount derivation index
subtargetYesType of anchor operation: "service" for service clients, "lib" for lib modules, "metadata" for Resolver.Metadata shortcuts
serviceNameNoRequired when subtarget is "service". The anchor service name (e.g. "FX", "KYC", "AssetMovement", "Username", "Notification", or any new service). Use keeta_list_sdk_methods with target "AnchorCatalog" to see available services.
libModuleNoRequired when subtarget is "lib". The lib module name (e.g. "Resolver", "Certificates", "EncryptedContainer", "URI", or any new module). Use keeta_list_sdk_methods with target "AnchorCatalog" to see available modules.
methodYesMethod name to call on the target
argsNoArguments array — each element is auto-resolved
rootAddressNoAnchor root account address. Defaults to the network root.

TDQS

A4.6/5.0
Behavior4/5

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

With no annotations provided, the description carries full burden and does well by explaining the dynamic runtime discovery system, auto-resolution of arguments, and the three subtarget types with their specific behaviors. It mentions seed omission for read-only operations (implied in schema but reinforced here). Could improve by explicitly stating whether operations are read-only or mutating.

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 efficiently structured with a clear opening statement, bulleted subtarget explanations, and specific guidance sentences. Every sentence serves a distinct purpose with zero wasted content, making it easy to parse despite the tool's complexity.

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 complex 9-parameter tool with no annotations and no output schema, the description provides substantial context about the execution model, subtarget semantics, and discovery mechanisms. It references related tools for additional functionality. Could be more complete by explaining return value expectations or error handling.

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?

With 100% schema description coverage, the baseline is 3, but the description adds significant value by explaining the semantic meaning of subtarget types (service, lib, metadata) with concrete examples, clarifying the relationship between parameters, and providing discovery guidance that goes beyond schema documentation.

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 states the tool executes ANY anchor operation on the Keeta Network with fully dynamic runtime discovery. It distinguishes from siblings by specifying this is for anchor operations specifically, unlike keeta_client_execute or keeta_user_client_execute which handle different execution contexts.

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?

The description provides explicit guidance on when to use different subtargets (service, lib, metadata) and directs users to keeta_list_sdk_methods for discovery. It also references keeta_client_execute for argument resolution rules, creating clear relationships with sibling tools.

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

keeta_builder_executeA

Execute a sequence of operations using the UserClient Builder pattern, then optionally compute and publish.

The builder batches multiple operations into blocks for efficient on-chain execution. Each operation in the "operations" array is an object with "method" and "args".

Use keeta_list_sdk_methods with target "Builder" to discover available methods.

Common builder methods: send, setInfo, modifyTokenSupply, modifyTokenBalance, computeBlocks, receive.

The tool will:

  1. Create a UserClient and initialize a builder

  2. Call each operation in sequence

  3. If autoPublish is true (default): call computeBlocks() then publish()

  4. Return all computed block hashes

Example operations: [ { "method": "setInfo", "args": [{ "name": "TKNA", "description": "My Token" }], "options": { "account": "keeta_..." } }, { "method": "modifyTokenSupply", "args": ["BIGINT:50000000000"], "options": { "account": "keeta_..." } }, { "method": "send", "args": ["keeta_recipient...", "BIGINT:1000000", "keeta_token..."] } ]

Arguments are auto-resolved (see keeta_client_execute for resolution rules). The "options" field in each operation is passed as the last argument (common for { account: tokenAddress }).

ParametersJSON Schema
NameRequiredDescriptionDefault
networkYesNetwork to use
seedYesSeed of the account
accountIndexNoAccount derivation index
operationsYesSequence of builder operations
autoPublishNoAutomatically compute and publish blocks after all operations

TDQS

A4/5.0
Behavior3/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It explains the multi-step process (create client, call operations, optionally compute/publish) and mentions auto-resolving arguments, but lacks details on permissions, rate limits, error handling, or what happens if operations fail mid-sequence.

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?

The description is appropriately sized and front-loaded with the core purpose. Each sentence adds value: explaining the builder pattern, referencing discovery tools, listing common methods, detailing the execution flow, providing examples, and clarifying argument resolution. Minor room for tightening exists in the example section.

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

Completeness3/5

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

For a complex tool with 5 parameters, no annotations, and no output schema, the description is adequate but has gaps. It covers the execution flow and parameter semantics well, but lacks information about return values (only mentions 'block hashes' briefly), error conditions, and operational constraints that would help an agent use it safely.

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 100%, so the baseline is 3. The description adds significant value by explaining the structure of operations objects (method, args, options), providing example operations, clarifying that 'options' is passed as the last argument, and noting auto-resolving behavior. This compensates well beyond the schema's technical documentation.

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 states the tool executes a sequence of operations using the UserClient Builder pattern, with specific verbs ('execute', 'compute', 'publish') and resources ('operations', 'blocks'). It distinguishes from siblings like keeta_client_execute by focusing on the builder pattern for batching operations.

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 provides clear context for when to use this tool (for batching multiple operations into blocks) and references keeta_list_sdk_methods for discovering available methods. However, it doesn't explicitly state when NOT to use it or compare it to alternatives like keeta_client_execute for single operations.

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

keeta_client_executeA

Execute any method on the Keeta Client (read-only network operations).

Use keeta_list_sdk_methods with target "Client" to discover available methods.

Common methods: getAccountInfo, getBalance, getAllBalances, getHeadBlock, getBlock, getHistory, getTokenSupply, getNetworkStatus, getPeers, getVersion, getLedgerChecksum, getAllCertificates, getAllRepresentativeInfo.

Arguments are auto-resolved:

  • Strings starting with "keeta_" become Account objects

  • "BIGINT:123" becomes BigInt(123)

  • "PERM:ACCESS,ADMIN" becomes a Permissions object

  • "ALGO:TOKEN" becomes AccountKeyAlgorithm.TOKEN

  • Plain strings, numbers, booleans, objects, arrays pass through as-is

ParametersJSON Schema
NameRequiredDescriptionDefault
networkYesNetwork to connect to
methodYesMethod name to call on Client
argsNoArguments array — each element is auto-resolved

TDQS

A4.6/5.0
Behavior4/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key traits: it's for 'read-only network operations' (indicating safety), mentions auto-resolution of arguments (important behavioral detail), and lists common methods. However, it doesn't cover potential rate limits, error handling, or response formats, leaving some gaps.

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 and front-loaded with the core purpose. Each sentence adds essential information: purpose, discovery method, common examples, and argument resolution rules. There's no wasted text, and it efficiently communicates complex concepts in a compact form.

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?

Given the tool's complexity (executing arbitrary methods with auto-resolved arguments) and lack of annotations or output schema, the description does a good job of covering key aspects: purpose, usage, and parameter behavior. However, it doesn't explain return values or potential errors, which could be important for a tool with no output schema, leaving some contextual gaps.

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 100%, so the baseline is 3. The description adds significant value beyond the schema by explaining how 'args' are auto-resolved with specific examples (e.g., strings starting with 'keeta_' become Account objects). This clarifies parameter semantics that aren't evident from the schema alone, though it doesn't detail 'network' or 'method' beyond what the schema provides.

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 states the tool's purpose: 'Execute any method on the Keeta Client (read-only network operations).' It specifies the exact resource (Keeta Client) and verb (execute methods), and distinguishes it from siblings by emphasizing 'read-only network operations' and referencing keeta_list_sdk_methods for discovery.

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?

The description provides explicit guidance on when to use this tool: 'Use keeta_list_sdk_methods with target "Client" to discover available methods.' It also lists common methods as examples, helping users understand typical use cases versus alternatives like keeta_user_client_execute or other sibling tools.

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

keeta_derive_accountA

Derive a Keeta account (public/private keypair) from a seed and index.

Each unique (seed, index, algorithm) combination produces a deterministic account. The returned address (keeta_...) is used in all other tools as account/token identifiers.

Supported algorithms:

  • SECP256K1 (default) — most common, Ethereum-compatible

  • SECP256R1 — WebAuthn/passkey compatible

  • ED25519 — fast signatures

Returns: { address: string, algorithm: string, index: number }

ParametersJSON Schema
NameRequiredDescriptionDefault
seedYesSeed string from keeta_generate_seed
indexYesDerivation index (0, 1, 2, ...)
algorithmNoKey algorithm — defaults to SECP256K1

TDQS

A4.2/5.0
Behavior4/5

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

With no annotations provided, the description carries the full burden and does well. It discloses key behavioral traits: deterministic output based on seed/index/algorithm combinations, the format of the returned address ('keeta_...'), and its role as an identifier in other tools. It doesn't cover error cases, performance, or security implications, but provides solid operational context.

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 efficiently structured: the first sentence states the core purpose, followed by key behavioral details, supported algorithms with brief context, and return format. Every sentence adds value with zero waste, and it's appropriately sized for a 3-parameter tool with no annotations.

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 derivation tool with no annotations and no output schema, the description is quite complete. It explains the deterministic behavior, address format usage, algorithm options, and return structure. It doesn't cover error handling or edge cases, but given the straightforward schema and clear purpose, it provides sufficient context for an agent to use the tool effectively.

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 schema already documents all parameters thoroughly. The description adds minimal value beyond the schema: it mentions the seed comes from keeta_generate_seed and lists algorithm options with brief explanations, but doesn't provide additional syntax, constraints, or examples. Baseline 3 is appropriate when the schema does the heavy lifting.

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 states the specific action ('derive a Keeta account'), the resource ('public/private keypair'), and the inputs ('from a seed and index'). It distinguishes from sibling tools like keeta_generate_seed (which creates seeds) and keeta_request_test_tokens (which requests tokens) by focusing on deterministic key derivation.

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 provides clear context for when to use this tool: to create deterministic accounts from seeds and indices, with the returned address used in other tools. It doesn't explicitly state when not to use it or name alternatives among siblings, but the purpose naturally differentiates it from tools like keeta_generate_seed or execution tools.

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

keeta_generate_seedA

Generate a new random cryptographic seed for the Keeta Network.

This is the starting point for all Keeta operations. A seed can derive unlimited accounts via keeta_derive_account. Store the seed securely — it controls all derived accounts and their funds.

Returns: { seed: string }

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.5/5.0
Behavior4/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key traits: the tool generates a random seed, which is foundational for deriving accounts and controlling funds, and emphasizes security implications. It also specifies the return format. While it covers critical aspects, it lacks details like rate limits or error handling, but this is sufficient for a high score given the context.

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 front-loaded with the core purpose in the first sentence, followed by essential context and a security warning, and ends with the return value. Every sentence adds value without waste, making it highly efficient and well-structured.

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 tool's complexity (simple generation with no parameters), no annotations, no output schema, and rich sibling context, the description is complete. It explains what the tool does, its role in the ecosystem, security considerations, and the return format, providing all necessary information for an AI agent to use it 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 tool has 0 parameters, and the schema description coverage is 100%, so the baseline is 4. The description does not need to add parameter information, and it appropriately focuses on the tool's purpose and output without redundancy.

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 states the tool's purpose with a specific verb ('Generate') and resource ('new random cryptographic seed for the Keeta Network'). It distinguishes this from sibling tools like keeta_derive_account by explaining that the seed is the starting point for deriving accounts, making its role explicit and unique.

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 provides clear context on when to use this tool: as the 'starting point for all Keeta operations' and to derive accounts via keeta_derive_account. It includes a security warning about storing the seed securely. However, it does not explicitly state when not to use it or name alternatives, which prevents a perfect score.

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

keeta_get_network_configB

Get the configuration for a Keeta network, including the network ID, base token address, and network account address.

This is useful for understanding the network you are operating on before making transactions.

Returns: { networkAlias, networkId, baseToken, networkAddress }

ParametersJSON Schema
NameRequiredDescriptionDefault
networkYesNetwork alias

TDQS

B3.3/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool 'Get[s]' configuration and describes the return values, but it doesn't mention whether this is a read-only operation, if it requires authentication, potential rate limits, or error conditions. For a tool with zero annotation coverage, this leaves significant behavioral gaps, though it does add some context about the return structure.

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 appropriately sized and front-loaded: the first sentence clearly states the purpose, the second provides usage context, and the third specifies return values. Every sentence adds value without redundancy, and there's no wasted text. It efficiently conveys necessary information in a structured manner.

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

Completeness3/5

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

Given the tool's low complexity (1 parameter, no nested objects) and 100% schema coverage, the description is somewhat complete but has gaps. It explains the purpose and return values, but with no output schema and no annotations, it lacks details on behavioral aspects like safety or errors. For a simple read operation, this is adequate but not fully comprehensive, as it could benefit from more transparency about operational constraints.

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?

The input schema has 100% description coverage, with the 'network' parameter documented as 'Network alias' and an enum of ['main', 'test']. The description doesn't add any parameter-specific semantics beyond what the schema provides (e.g., it doesn't explain what 'main' or 'test' mean in context). Since schema coverage is high, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't need to given the schema's completeness.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Get' and resource 'configuration for a Keeta network', specifying what information is included (network ID, base token address, network account address). It distinguishes itself from siblings like keeta_anchor_execute or keeta_request_test_tokens by focusing on configuration retrieval rather than execution or token requests. However, it doesn't explicitly contrast with keeta_list_sdk_methods which might also provide informational content.

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

Usage Guidelines3/5

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

The description provides implied usage guidance by stating 'This is useful for understanding the network you are operating on before making transactions,' which suggests using this tool for preparatory checks. However, it lacks explicit alternatives (e.g., when to use keeta_derive_account instead) or clear exclusions (e.g., when not to use it if you already have the configuration). The guidance is helpful but not comprehensive.

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

keeta_list_sdk_methodsA

Discover available methods and properties on Keeta SDK objects at runtime. Use this FIRST to understand what operations are available before calling execute tools.

The "target" parameter accepts:

Core SDK (fixed): "Client" → read-only network queries "UserClient" → authenticated operations "Builder" → batch transaction builder "Account" → account utilities + enums "Block" → block types + operation enums "Permissions" → permission construction "Config" → network configuration

Anchor SDK (dynamic — auto-discovers new services): "AnchorCatalog" → list ALL available anchor services and lib modules (start here!) "AnchorService:" → methods on a specific anchor service client (e.g. "AnchorService:FX", "AnchorService:KYC", "AnchorService:AssetMovement", "AnchorService:Username", "AnchorService:Notification", or ANY new service the SDK adds) "AnchorLib:" → methods on a specific anchor lib module (e.g. "AnchorLib:Resolver", "AnchorLib:Certificates", "AnchorLib:EncryptedContainer", "AnchorLib:URI", or ANY new module)

When in doubt, start with "AnchorCatalog" to see everything available, then drill into specific services/modules.

ParametersJSON Schema
NameRequiredDescriptionDefault
targetYesSDK target to introspect. Fixed values: "Client", "UserClient", "Builder", "Account", "Block", "Permissions", "Config", "AnchorCatalog". Dynamic: "AnchorService:<Name>" or "AnchorLib:<Name>".
networkNoNetwork for instantiation (needed for Client/UserClient/Builder)test

TDQS

A4.6/5.0
Behavior4/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes the tool's behavior: it's for runtime discovery, lists specific target categories (Core SDK fixed vs. Anchor SDK dynamic), and explains how dynamic targets auto-discover new services. However, it lacks details on output format, rate limits, or error handling, which are minor gaps.

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 and front-loaded with the core purpose. Each sentence earns its place by providing essential information: purpose, usage guidelines, parameter details, and examples. It avoids redundancy and is appropriately sized for the tool's complexity.

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?

Given the tool's complexity (runtime discovery with dynamic targets) and no output schema, the description is mostly complete. It covers purpose, usage, parameter semantics, and behavioral context. However, it doesn't describe the return format or what the discovered methods/properties look like, which is a minor gap given the lack of output schema.

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 description coverage is 100%, so the baseline is 3. The description adds significant value by explaining the semantics of the 'target' parameter in detail, categorizing Core SDK vs. Anchor SDK, listing fixed and dynamic values with examples, and providing usage tips (e.g., 'start with AnchorCatalog'). This goes well beyond the schema's enum and description.

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 states the tool's purpose: 'Discover available methods and properties on Keeta SDK objects at runtime.' It specifies the verb ('discover') and resource ('methods and properties on Keeta SDK objects'), and distinguishes it from sibling tools like execute tools by advising to use it FIRST to understand available operations.

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?

The description provides explicit guidance on when to use this tool: 'Use this FIRST to understand what operations are available before calling execute tools.' It includes alternatives for dynamic targets ('start with "AnchorCatalog" to see everything available, then drill into specific services/modules') and clarifies usage contexts (e.g., 'When in doubt, start with...').

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

keeta_request_test_tokensA

Request free KTA tokens from the Keeta test network faucet.

Only works on the test network. Sends 5 KTA to the given address for development/testing. KTA is needed for transaction fees on the network.

Returns: { status, address, amountRequested, currentBalance }

ParametersJSON Schema
NameRequiredDescriptionDefault
addressYesKeeta address (keeta_...) to fund

TDQS

A4.2/5.0
Behavior4/5

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

With no annotations provided, the description carries full burden and does well: it discloses the network constraint (test only), the fixed amount (5 KTA), the purpose (development/testing), and what KTA is used for (transaction fees). It also describes the return structure. It doesn't mention rate limits or authentication needs, but covers key behavioral aspects.

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 front-loaded with the core purpose, followed by constraints and return details. Every sentence earns its place: first states what it does, second specifies network and amount, third explains KTA's role, fourth documents returns. No wasted words, appropriately sized for the tool's complexity.

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 single-parameter tool with no annotations and no output schema, the description is quite complete: it explains purpose, constraints, amount, usage context, and return structure. The only minor gap is lack of explicit error cases or rate limit info, but it covers most essential context given the tool's simplicity.

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%, with the single parameter 'address' documented as 'Keeta address (keeta_...) to fund'. The description adds that it's 'the given address' and implies it receives tokens, but doesn't provide additional syntax or format details beyond what the schema already states. Baseline 3 is appropriate when schema does the heavy lifting.

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 states the specific action ('Request free KTA tokens'), resource ('from the Keeta test network faucet'), and scope ('Only works on the test network'). It distinguishes this tool from siblings like keeta_anchor_execute or keeta_builder_execute by focusing on faucet functionality rather than execution or account management.

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 explicitly states 'Only works on the test network' and mentions 'for development/testing', providing clear context for when to use this tool. However, it doesn't specify when NOT to use it (e.g., for production) or name alternatives explicitly, though the sibling tools suggest other options for different operations.

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

keeta_user_client_executeA

Execute any method on the Keeta UserClient (authenticated operations requiring an account).

Use keeta_list_sdk_methods with target "UserClient" to discover available methods.

Common methods: allBalances, balance, head, chain, history, state, send, setInfo, generateIdentifier, updatePermissions, createSwapRequest, transmit, listACLsByPrincipal, getCertificates, modifyCertificate, sync.

Properties you can read (pass method "GET_PROPERTY" with args ["propertyName"]): baseToken, networkAddress, network, account, signer.

Arguments are auto-resolved (see keeta_client_execute for resolution rules).

ParametersJSON Schema
NameRequiredDescriptionDefault
networkYesNetwork to connect to
seedNoSeed of the account. Omit for read-only operations (null account).
accountIndexNoAccount derivation index
methodYesMethod name to call on UserClient, or "GET_PROPERTY" to read a property
argsNoArguments array — each element is auto-resolved

TDQS

A4.2/5.0
Behavior3/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It adds valuable context: it mentions 'authenticated operations requiring an account,' lists common methods and properties, and references auto-resolution rules via keeta_client_execute. However, it lacks details on error handling, rate limits, or specific authentication requirements beyond the seed parameter, leaving gaps for a mutation-capable tool.

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?

The description is appropriately sized and front-loaded, starting with the core purpose. Each sentence adds value: the first defines the tool, the second guides usage, the third lists methods, the fourth details properties, and the fifth explains argument resolution. There's minimal waste, though the list of common methods is somewhat lengthy but informative.

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

Completeness3/5

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

Given the tool's complexity (5 parameters, no annotations, no output schema), the description is moderately complete. It covers purpose, usage, methods, properties, and argument resolution, but lacks details on return values, error cases, or specific behavioral traits like side effects or permissions. Without annotations or output schema, more context on what to expect from executions would improve completeness.

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 100%, so the baseline is 3. The description adds meaningful semantics beyond the schema: it explains that 'Arguments are auto-resolved (see keeta_client_execute for resolution rules),' clarifies that 'GET_PROPERTY' is used for reading properties with examples, and lists common methods and properties, enhancing understanding of the 'method' and 'args' parameters. This elevates the score above baseline.

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 states the tool's purpose: 'Execute any method on the Keeta UserClient (authenticated operations requiring an account).' It specifies the verb ('execute'), resource ('Keeta UserClient'), and scope ('authenticated operations requiring an account'), distinguishing it from sibling tools like keeta_client_execute (which handles argument resolution) and keeta_list_sdk_methods (which lists methods).

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?

The description provides explicit guidance on when to use this tool: it directs users to 'Use keeta_list_sdk_methods with target "UserClient" to discover available methods,' naming a specific alternative tool. It also clarifies that it's for 'authenticated operations requiring an account,' implying keeta_client_execute might be for non-authenticated or general cases, though not explicitly stated as an exclusion.

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

Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.1/5.0
Disambiguation4/5

Most tools have distinct purposes, such as keeta_derive_account for key derivation and keeta_request_test_tokens for faucet access. However, keeta_anchor_execute, keeta_builder_execute, keeta_client_execute, and keeta_user_client_execute all involve executing SDK methods, which could cause confusion about which to use for specific operations, though their descriptions clarify different contexts (anchor operations, builder patterns, read-only client, authenticated client).

Naming Consistency5/5

All tool names follow a consistent snake_case pattern with a 'keeta_' prefix and descriptive verb_noun combinations, such as keeta_anchor_execute, keeta_list_sdk_methods, and keeta_generate_seed. This uniformity makes the tool set predictable and easy to navigate.

Tool Count5/5

With 9 tools, the server is well-scoped for interacting with the Keeta Network, covering essential operations like account management, network queries, transaction building, and SDK discovery. Each tool serves a clear purpose without redundancy, fitting typical MCP server ranges.

Completeness5/5

The tool set provides comprehensive coverage for the Keeta Network domain, including account derivation, seed generation, network configuration, SDK method discovery, test token acquisition, and various execution contexts (client, user client, anchor, builder). There are no obvious gaps, enabling full lifecycle management from setup to transaction execution.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

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/schenkty/kta-mcp'

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