Skip to main content
Glama

sign_raw_transaction

sign_raw_transaction

Sign a raw VeChain transaction to authorize blockchain operations using cryptographic verification.

Instructions

Decode and sign a raw transaction.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
rawTransactionYes

Implementation Reference

  • Handler function that signs a raw VeChain transaction using the agent's secret key from environment variable. Decodes the hex input, signs with secp256k1, encodes, and returns the signed transaction hex.
    callback: async ({ rawTransaction }: { rawTransaction: string }) => {
        const secretKey = process.env.AGENT_SECRET_KEY
    
        if (!secretKey) {
            throw new Error("Missing AGENT_SECRET_KEY variable to use this tool.")
        }
    
        const secretKeyBytes = Address.of(secretKey).bytes
    
        const decodedTxBytes = Hex.of(rawTransaction).bytes
        const decodedTx = Transaction.decode(decodedTxBytes, true);
    
        const signedTx = decodedTx.sign(secretKeyBytes)
        const signedTxBytes = signedTx.encoded
        const signedTxHex = Hex.of(signedTxBytes).toString()
    
        return {
            content: [{
                type: "text",
                text: JSON.stringify(signedTxHex, null, 2)
            }]
        };
    
    }
  • Zod input schema defining the required 'rawTransaction' parameter as a string (hex-encoded raw transaction).
    inputSchema: {
        rawTransaction: z.string(),
    },
  • src/server.ts:74-92 (registration)
    Registration of all vechainTools (including sign_raw_transaction) with the MCP server using registerTool, passing name, schema, and wrapper around the tool's callback.
    for (const t of vechainTools) {
      server.registerTool(
        t.name,
        {
          title: t.name,
          description: t.description,
          inputSchema: t.inputSchema
        },
        async (args) => {
          const result = await t.callback(args);
          return {
            content: result.content.map(item => ({
              ...item,
              type: "text" as const
            }))
          };
        }
      );
    }
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 mentions 'decode and sign' but doesn't explain what decoding entails, whether this requires private keys or authentication, if it's a read-only or destructive operation, or what the output looks like. This leaves significant gaps for a signing tool.

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 extremely concise with a single sentence, front-loaded with the core action. There is no wasted text, making it efficient and easy to parse, though this brevity contributes to gaps in other dimensions.

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

Completeness2/5

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

Given the complexity of a signing operation, lack of annotations, no output schema, and 0% schema coverage, the description is incomplete. It doesn't cover behavioral aspects like security implications, output format, or error handling, which are critical for such a tool in this context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/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 for undocumented parameters. It implies 'rawTransaction' is the input but doesn't add meaning beyond the schema, such as the expected format (e.g., hex string), encoding, or constraints. This fails to address the coverage gap adequately.

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

Purpose3/5

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

The description states the tool's purpose with the verbs 'decode and sign' and the resource 'a raw transaction', which is clear but somewhat vague. It doesn't specify what type of transaction (e.g., blockchain/EVM) or distinguish it from sibling tools like sign_message or sign_typed_data_evm, which also involve signing operations.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives. With sibling tools like sign_message and sign_typed_data_evm available, the description lacks context on when this specific signing method is appropriate, such as for raw transaction data versus structured messages.

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/leandrogavidia/vechain-mcp-server'

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