Skip to main content
Glama
The-40-Thieves

obsidian-tc

by The-40-Thieves
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Call capability

call_capability

Invoke a named capability with arguments, routing through the same authorization, ACL, human-in-the-loop, idempotency, and rate-limit pipeline as direct tool calls, while validating arguments against the target's schema.

Instructions

Invoke a capability by name with its arguments. Routes into the same authorization, ACL, HITL, idempotency, and rate-limit pipeline as a direct tool call, so every safety gate applies and the target's own schema validates the arguments.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
argsYes
nameYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4/5.0
Behavior4/5

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

The description proactively discloses that the call goes through authorization, ACL, HITL, idempotency, and rate-limit pipelines, which is important behavioral context. It does not mention output/return behavior or potential side effects, but the lack of output schema and the generic 'invoke' wording keep this from being misleading.

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 concise, consisting of two sentences with no redundant or extraneous information. It delivers key behavioral details efficiently.

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?

For a generic invocation tool, the description covers the main purpose, safety pipeline, and argument validation. It does not mention how to discover capability names or what the return value looks like, but sibling tool names and the absence of an output schema reduce the need for that detail.

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 schema provides names and types for the two parameters, and the description adds that 'name' is the capability name and 'args' are its arguments. There are no detailed parameter descriptions, but the description adequately maps the parameters to their intended roles.

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 tool invokes a capability by name with its arguments, which is a specific action distinct from the sibling find/describe tools. It also explains the routing and safety pipeline, making the purpose 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?

The description explains how the tool behaves but does not explicitly state when to use this tool versus the sibling find_capability or describe_capability. The sibling names imply the distinction, but the description itself lacks direct usage guidance for choosing among them.

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

Deploy Server

Other Tools