Skip to main content
Glama

contract_call_raw_function

Execute a raw function call on a NEAR contract, creating a transaction with gas and NEAR costs. Specify account IDs, method name, arguments, gas, and deposit for precise execution on testnet or mainnet.

Instructions

Call a function of a contract as a raw function call action. This tool creates a function call as a transaction which costs gas and NEAR.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
accountIdYesThe account id of the signer.
argsYesThe arguments to pass to the method.
attachedDepositNoThe amount to attach to the function call (default to 1 yoctoNEAR). Can be specified as a number (in NEAR) or as a bigint (in yoctoNEAR).
contractAccountIdYesThe account id of the contract.
gasNoThe amount of gas to use for the function call in yoctoNEAR (default to 30TGas).
methodNameYesThe name of the method to call.
networkIdNomainnet

Implementation Reference

  • Handler function that performs a raw function call to a NEAR smart contract using the signer account's key from the keystore. It connects to the network, validates the contract account, executes the function call with specified args, gas, and deposit, and returns the transaction result.
    async (args, _) => {
      const connection = await connect({
        networkId: args.networkId,
        keyStore: keystore,
        nodeUrl: getEndpointsByNetwork(args.networkId)[0]!,
      });
    
      const contractAccountResult: Result<Account, Error> = await getAccount(
        args.contractAccountId,
        connection,
      );
      if (!contractAccountResult.ok) {
        return {
          content: [
            {
              type: 'text',
              text: `Error: ${contractAccountResult.error}`,
            },
          ],
        };
      }
      const contractAccount = contractAccountResult.value;
    
      const functionCallResult: Result<unknown, Error> = await (async () => {
        try {
          const deposit =
            typeof args.attachedDeposit === 'number'
              ? NearToken.parse_near(
                  args.attachedDeposit.toString(),
                ).as_yocto_near()
              : args.attachedDeposit;
          const signerAccount = await connection.account(args.accountId);
          return {
            ok: true,
            value: await signerAccount.functionCall({
              contractId: contractAccount.accountId,
              methodName: args.methodName,
              args: args.args,
              gas: args.gas || DEFAULT_GAS,
              attachedDeposit: deposit,
            }),
          };
        } catch (e) {
          return { ok: false, error: new Error(e as string) };
        }
      })();
      if (!functionCallResult.ok) {
        return {
          content: [
            {
              type: 'text',
              text: `Error: ${functionCallResult.error}`,
            },
          ],
        };
      }
      return {
        content: [
          {
            type: 'text',
            text: `Function call result: ${stringify_bigint(functionCallResult.value)}`,
          },
        ],
      };
    },
  • Zod schema defining the input parameters for the contract_call_raw_function tool: accountId (signer), contractAccountId, methodName, networkId, args (record), optional gas (bigint), attachedDeposit (number or bigint).
      accountId: z.string().describe('The account id of the signer.'),
      contractAccountId: z.string().describe('The account id of the contract.'),
      methodName: z.string().describe('The name of the method to call.'),
      networkId: z.enum(['testnet', 'mainnet']).default('mainnet'),
      args: z
        .record(z.string(), z.any())
        .describe('The arguments to pass to the method.'),
      gas: z
        .bigint()
        .optional()
        .describe(
          'The amount of gas to use for the function call in yoctoNEAR (default to 30TGas).',
        ),
      attachedDeposit: z
        .union([
          z.number().describe('The amount of NEAR tokens (in NEAR)'),
          z.bigint().describe('The amount in yoctoNEAR'),
        ])
        .default(NearToken.parse_yocto_near('1').as_near())
        .describe(
          'The amount to attach to the function call (default to 1 yoctoNEAR). Can be specified as a number (in NEAR) or as a bigint (in yoctoNEAR).',
        ),
    },
  • MCP tool registration using mcp.tool() with name 'contract_call_raw_function', description, input schema, and handler callback.
      'contract_call_raw_function',
      noLeadingWhitespace`
      Call a function of a contract as a raw function call action. This tool creates a function call
      as a transaction which costs gas and NEAR.`,
      {
        accountId: z.string().describe('The account id of the signer.'),
        contractAccountId: z.string().describe('The account id of the contract.'),
        methodName: z.string().describe('The name of the method to call.'),
        networkId: z.enum(['testnet', 'mainnet']).default('mainnet'),
        args: z
          .record(z.string(), z.any())
          .describe('The arguments to pass to the method.'),
        gas: z
          .bigint()
          .optional()
          .describe(
            'The amount of gas to use for the function call in yoctoNEAR (default to 30TGas).',
          ),
        attachedDeposit: z
          .union([
            z.number().describe('The amount of NEAR tokens (in NEAR)'),
            z.bigint().describe('The amount in yoctoNEAR'),
          ])
          .default(NearToken.parse_yocto_near('1').as_near())
          .describe(
            'The amount to attach to the function call (default to 1 yoctoNEAR). Can be specified as a number (in NEAR) or as a bigint (in yoctoNEAR).',
          ),
      },
      async (args, _) => {
        const connection = await connect({
          networkId: args.networkId,
          keyStore: keystore,
          nodeUrl: getEndpointsByNetwork(args.networkId)[0]!,
        });
    
        const contractAccountResult: Result<Account, Error> = await getAccount(
          args.contractAccountId,
          connection,
        );
        if (!contractAccountResult.ok) {
          return {
            content: [
              {
                type: 'text',
                text: `Error: ${contractAccountResult.error}`,
              },
            ],
          };
        }
        const contractAccount = contractAccountResult.value;
    
        const functionCallResult: Result<unknown, Error> = await (async () => {
          try {
            const deposit =
              typeof args.attachedDeposit === 'number'
                ? NearToken.parse_near(
                    args.attachedDeposit.toString(),
                  ).as_yocto_near()
                : args.attachedDeposit;
            const signerAccount = await connection.account(args.accountId);
            return {
              ok: true,
              value: await signerAccount.functionCall({
                contractId: contractAccount.accountId,
                methodName: args.methodName,
                args: args.args,
                gas: args.gas || DEFAULT_GAS,
                attachedDeposit: deposit,
              }),
            };
          } catch (e) {
            return { ok: false, error: new Error(e as string) };
          }
        })();
        if (!functionCallResult.ok) {
          return {
            content: [
              {
                type: 'text',
                text: `Error: ${functionCallResult.error}`,
              },
            ],
          };
        }
        return {
          content: [
            {
              type: 'text',
              text: `Function call result: ${stringify_bigint(functionCallResult.value)}`,
            },
          ],
        };
      },
    );
Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. It mentions that the call creates a transaction with gas and NEAR costs, which is useful context. However, it doesn't describe what happens on failure, whether the transaction is atomic, what permissions are required, or what the response format might be. For a state-changing tool with significant financial implications, this is inadequate behavioral transparency.

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 concise with two sentences that convey the core operation and its cost implications. It's front-loaded with the main purpose. While efficient, it could potentially benefit from slightly more detail given the complexity of the operation, but it avoids unnecessary verbosity.

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?

For a complex state-changing tool with 7 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what happens after the call, what constitutes success/failure, or how to interpret results. The financial implications (gas and NEAR costs) are mentioned but not elaborated. Given the tool's complexity and lack of structured metadata, the description should provide more complete context.

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 description provides no parameter-specific information beyond what's already in the schema. With 86% schema description coverage (high), the schema already documents most parameters well. The description doesn't add any additional context about parameter relationships, constraints, or usage patterns beyond the basic operation. This meets the baseline for high schema coverage but doesn't enhance understanding.

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 action ('Call a function of a contract') and resource ('as a raw function call action'), making the purpose understandable. It distinguishes from the sibling 'contract_call_raw_function_as_read_only' by mentioning transaction costs, but doesn't explicitly contrast them. The description is specific about the operation type but could be more precise about what differentiates it from other contract interaction tools.

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?

The description mentions that this creates a transaction costing gas and NEAR, which provides some context about when to use it (for state-changing operations). However, it doesn't explicitly state when to use this versus the read-only sibling or other contract interaction tools. No guidance is provided about prerequisites, alternatives, or exclusions beyond the basic cost implication.

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

Related 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/nearai/near-mcp'

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