Skip to main content
Glama

call-tool

Execute a specific tool from a designated MCP server by providing the server name, tool name, and arguments. Use after identifying tools with find-tools.

Instructions

Call a specific tool from a specific server. TIP: Use find-tools first to discover the tool and get the correct serverName and toolName

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
serverNameYesName of the MCP server to call tool from
toolArgsYesArguments to pass to the tool
toolNameYesName of the tool to call

Implementation Reference

  • Handler function for the 'call-tool' tool. Destructures arguments, calls serverManager.callTool, and returns the result as JSON text content or an error.
    async (args, extra) => {
      try {
        const { serverName, toolName, toolArgs } = args;
        const result = await serverManager.callTool(
          serverName,
          toolName,
          toolArgs,
        );
    
        return {
          content: [
            {
              type: "text",
              text: JSON.stringify(result, null, 2),
            },
          ],
        };
      } catch (error) {
        return {
          content: [
            {
              type: "text",
              text: `Tool call failed: ${(error as Error).message}`,
            },
          ],
          isError: true,
        };
      }
    },
  • src/index.ts:97-134 (registration)
    Registration of the 'call-tool' tool on the MCP server, including name, description, input schema derived from CallToolParamsSchema, and handler function.
    server.tool(
      "call-tool",
      "Call a specific tool from a specific server. TIP: Use find-tools first to discover the tool and get the correct serverName and toolName",
      {
        serverName: CallToolParamsSchema.shape.serverName,
        toolName: CallToolParamsSchema.shape.toolName,
        toolArgs: CallToolParamsSchema.shape.toolArgs,
      },
      async (args, extra) => {
        try {
          const { serverName, toolName, toolArgs } = args;
          const result = await serverManager.callTool(
            serverName,
            toolName,
            toolArgs,
          );
    
          return {
            content: [
              {
                type: "text",
                text: JSON.stringify(result, null, 2),
              },
            ],
          };
        } catch (error) {
          return {
            content: [
              {
                type: "text",
                text: `Tool call failed: ${(error as Error).message}`,
              },
            ],
            isError: true,
          };
        }
      },
    );
  • Zod schema defining the input parameters for the 'call-tool' tool: serverName (string), toolName (string), toolArgs (record of unknown).
    export const CallToolParamsSchema = z.object({
      serverName: z
        .string()
        .describe("Name of the MCP server to call tool from"),
      toolName: z.string().describe("Name of the tool to call"),
      toolArgs: z
        .record(z.unknown())
        .describe("Arguments to pass to the tool"),
    });
    
    export type CallToolParams = z.infer<
      typeof CallToolParamsSchema
    >;
  • Helper method in McpServerManager class that retrieves the client for the server and calls the target tool using the MCP client SDK.
    async callTool(
      serverName: string,
      toolName: string,
      args: Record<string, unknown>
    ): Promise<any> {
      const client = this.getClient(serverName);
      return await client.callTool({
        name: toolName,
        arguments: args,
      });
    }
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. While it mentions the action of calling a tool, it lacks details on critical behaviors such as error handling, authentication requirements, rate limits, or what happens if the tool call fails. For a tool that executes arbitrary operations with no annotation coverage, this is a significant gap in transparency.

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 highly concise and front-loaded, consisting of two sentences that directly address the tool's purpose and usage guidelines. Every sentence adds value without redundancy, making it efficient and easy to parse for an AI agent.

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 (executing arbitrary tools with nested parameters) and the absence of both annotations and an output schema, the description is incomplete. It covers purpose and usage but lacks behavioral details like return values, error cases, or side effects. While it provides a minimum viable explanation, more context is needed for safe and effective use.

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 all parameters (serverName, toolName, toolArgs) well-documented in the schema. The description adds no additional semantic information beyond what the schema provides, such as examples or constraints on parameter values. However, the baseline score of 3 is appropriate since the schema adequately covers parameter details.

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 ('Call a specific tool') and resource ('from a specific server'), with the verb 'call' precisely indicating the operation. It distinguishes itself from sibling tools like 'find-tools' by focusing on execution rather than discovery, making the purpose unambiguous and well-defined.

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 versus alternatives: it instructs to 'Use find-tools first to discover the tool and get the correct serverName and toolName,' clearly indicating a prerequisite workflow and distinguishing it from discovery-focused siblings like 'find-tools' or 'list-servers.' This offers clear context for proper tool selection.

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/warpdev/mcp-hub-mcp'

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