run_tool

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

Since there are no annotations, the description carries the full behavioral disclosure burden. It does well by revealing that arguments are re-validated against the target tool's compiled inputSchema, that hidden static_filters and request tenancy still apply, and explicitly asserting this is not a bypass. This adds valuable behavioral context beyond the schema, even if it does not cover side effects or failure modes.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact—four sentences, each serving a distinct purpose: the essential action, the exact use-case, revalidation and constraints, and a caution against misuse. The most important information ('run by name', 'use for new tools') appears first, and no sentence is wasted.

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

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

The description covers the main use case, tool login source, and revalidation constraints, which is good for a generic dispatcher. However, given there is no output schema or annotations, it does not explain what the returned result looks like or how errors from the target tool are presented, leaving room for the agent to ask follow-up questions.

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

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already provides strong descriptions for both parameters: 'name' points to list_available_tools, and 'arguments' explains that validation happens against the target tool's inputSchema. The description adds a slight emphasis on re-validation and constraints, but overall the structured schema carries most of the parameter semantics, so a baseline 3 is appropriate.

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

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

The description states a clear verb and resource: 'Run any VectorSmith tool by name with its arguments from list_available_tools.' It clearly distinguishes this from the invoice-related sibling tools by presenting it as a generic dispatcher for tools not visible in the Desktop connector list. It is more specific than a tautology and provides enough scope to avoid confusion.

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

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

The description explicitly says when to use it: 'for tools added to tools.yaml after Claude connected; Desktop will not show those names in the connector list.' It also adds an important exclusion by stating 'Not a bypass' and noting that hidden filters still apply. However, it does not directly discuss using or avoiding sibling tools, though this generic dispatcher clearly does not conflict with them.

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