MCP Test MCP

Overview Schema Source Related Servers Discussions Admin

Call Tool

call_tool

Execute a named tool on a connected MCP server by passing its arguments, returning execution results and metadata. Use this to invoke any available tool and handle success or error responses.

Instructions

Execute a tool on the connected MCP server.

Calls a tool by name with the provided arguments and returns the result along with execution timing and metadata.

Returns: Dictionary with tool execution results including: - success: True if tool executed successfully - tool_call: Object with tool_name, arguments, result, and execution metadata - metadata: Request timing and server information

Raises: Returns error dict for various failure scenarios: - not_connected: No active connection - tool_not_found: Tool doesn't exist on server - invalid_arguments: Arguments don't match tool schema - execution_error: Tool execution failed

Input Schema

TableJSON Schema

Name	Required	Description	Default
`name`	Yes	Name of the tool to execute on the target MCP server
`arguments`	Yes	Dictionary of arguments to pass to the tool

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.5.2Sep 8, 2026
- addedInput schema / additionalProperties
```
Added value: +false
```
First observedDec 7, 2025

TDQS

A3.9/5.0

Behavior4/5

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

With no annotations, the description carries the full burden and does well by enumerating success fields and common failure modes such as not_connected, tool_not_found, invalid_arguments, and execution_error. It does not mention potential side effects, but the error list gives a solid behavioral picture.

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 well organized with clear Returns and Raises sections, making it easy to scan. It is slightly verbose with repeated metadata wording, but not enough to hurt usability.

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 is simple and the description covers invocation, success output, and failure modes, which is sufficient for an agent to call it correctly. It does not specify output types in detail, but the listed fields are adequate.

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 descriptions cover both parameters at 100%, so the description adds little beyond what is already in the schema. The parameter names and descriptions are clear, but no extra semantic detail or usage nuance is provided.

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?

Clearly states it executes a tool on the connected MCP server, distinguishing it from sibling tools like list_tools and list_resources. The verb 'execute' and resource 'tool' are specific and unambiguous.

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?

Implicitly indicates when to use it—when you need to invoke a tool by name with arguments—but does not explicitly contrast it with alternatives like list_tools for discovery or get_prompt for prompts. The error cases hint at prerequisites but no direct when-not guidance is provided.

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

Deploy Server