Skip to main content
Glama

Tokenbooks - crypto and fiat accounting and payments

Add Wallet(s) to Portfolio

add_wallet

Add one or more blockchain addresses and start their first sync. Omit the blockchain connection identifier (integrationId) to add an EVM 0x address on every supported EVM network; other addresses require an integrationId. This tool does not configure exchange accounts and reports which addresses were added or skipped.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
walletsYes
portfolioRefYesPortfolio name or slug inside that workspace. Call list_portfolios to resolve it.
workspaceRefYesWorkspace name or slug. Call list_workspaces to resolve it.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultsYes
syncQueuedYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedInput schema / properties / portfolioRef / description
      Previous value: -"Portfolio name or slug inside that workspace. Call list_portfolios, or find_portfolios when the user named one, to resolve it."New value: +"Portfolio name or slug inside that workspace. Call list_portfolios to resolve it."
    • changedInput schema / properties / workspaceRef / description
      Previous value: -"Workspace name or slug. Call list_workspaces, or find_workspaces when the user named one, to resolve it."New value: +"Workspace name or slug. Call list_workspaces to resolve it."
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "$schema": "https://json-schema.org/draft/2020-12/schema",
      +  "additionalProperties": false,
      +  "properties": {
      +    "results": {
      +      "items": {
      +        "additionalProperties": false,
      +        "properties": {
      +          "address": {
      +            "type": "string"
      +          },
      +          "chainRef": {
      +            "type": "string"
      +          },
      +          "reason": {
      +            "type": "string"
      +          },
      +          "status": {
      +            "enum": [
      +              "created",
      +              "skipped"
      +            ],
      +            "type": "string"
      +          }
      +        },
      +        "required": [
      +          "address",
      +          "status"
      +        ],
      +        "type": "object"
      +      },
      +      "type": "array"
      +    },
      +    "syncQueued": {
      +      "type": "boolean"
      +    }
      +  },
      +  "required": [
      +    "results",
      +    "syncQueued"
      +  ],
      +  "type": "object"
      +}
  2. Changed2 schema fields changed
    • addedInput schema / properties / portfolioRef / description
      Added value: +"Portfolio name or slug inside that workspace. Call list_portfolios, or find_portfolios when the user named one, to resolve it."
    • addedInput schema / properties / workspaceRef / description
      Added value: +"Workspace name or slug. Call list_workspaces, or find_workspaces when the user named one, to resolve it."
  3. First observed

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already indicate readOnlyHint=false and destructiveHint=false, so the safety profile is known. The description adds behavioral detail beyond annotations: it triggers an initial sync, reports which addresses were added or skipped (implying partial success), and explains the EVM chain-discovery behavior when integrationId is omitted. This is meaningful context that helps an agent predict tool behavior.

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?

Three sentences, each earning its place: the first states the core action, the second gives the critical integrationId rule, and the third provides exclusions and reporting behavior. No wasted words, front-loaded with the primary purpose.

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?

The tool has moderate complexity (nested wallets array, required workspace/portfolio refs) but the description, combined with the schema (which already points to list_portfolios/list_workspaces) and the output schema, gives an agent enough to call it correctly. It covers key behavior, exclusions, and the integrationId decision. A minor gap is not addressing what happens on duplicate addresses, but that is not critical for successful invocation.

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 67%, which is moderate, and the description adds value beyond the structured definitions. It clarifies that omitting integrationId means adding an EVM 0x address on every supported EVM network, and that non-EVM addresses require an integrationId. This conditional behavior is not fully spelled out in the schema's property descriptions, so the description meaningfully compensates for gaps.

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: 'Add one or more blockchain addresses and start their first sync.' It clearly distinguishes this tool from siblings like create_portfolio or list_wallets by focusing on adding addresses, and it adds a useful exclusion: 'This tool does not configure exchange accounts.' The EVM/integrationId nuance further scopes its purpose.

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 gives clear context for when to use the tool (adding blockchain addresses to a portfolio) and an explicit exclusion ('does not configure exchange accounts'). However, it does not name alternative sibling tools (e.g., list_wallets for viewing existing wallets) or state a specific when-not-to-use condition beyond the exchange account exclusion, so it stops short of a 5.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources