Skip to main content
Glama
tugraskan

swatplus-mcp

by tugraskan

callers

Retrieve the exhaustive list of routines that call a specified procedure, ensuring every caller is included without truncation.

Instructions

Routines that call this procedure. Exhaustive over the whole tree, never sampled or truncated -- one result means exactly one caller, not a partial list.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
procedureYesProcedure name

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.1

TDQS

A4.2/5.0
Behavior4/5

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

With no annotations provided, the description carries the full burden, and it delivers key behavioral guarantees: results are exhaustive, never sampled, never truncated, and each result maps to exactly one caller. This adds meaningful, non-obvious context beyond the input schema, though it does not describe output format or error behavior.

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 a single, front-loaded sentence that immediately states the tool's purpose, then adds a crucial behavioral guarantee. Every word earns its place, and there is no redundant fluff.

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 simple single-parameter query tool, the description sufficiently explains the tool's behavior and result semantics without needing an output schema. It could go further by describing the result format or handling of unknown procedures, but the core information needed to call it correctly is present.

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 already has 100% coverage for the single parameter, 'procedure', described as 'Procedure name'. The description adds no additional parameter-level detail, which is acceptable given the minimal parameter surface.

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 that this tool returns routines that call the specified procedure, and the explicit 'never sampled or truncated' guarantee distinguishes it from possibly partial or sampled alternatives. The focus on 'callers' is unambiguous and naturally separates it from the sibling 'callees' tool.

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

Usage Guidelines4/5

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

The description conveys when to use the tool: when an exhaustive, complete list of callers is needed. It clearly implies this is the authoritative source for caller information, but it does not explicitly name alternatives or state when not to use it.

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