Skip to main content
Glama
Sign In
PeerDB MCP

PeerDB MCP

by AMohammadzadeh
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

pause_pipeline

Destructive

Request a halt to a running PeerDB pipeline by name, then poll its status to confirm the pause completes.

Instructions

Request pause of a running pipeline. Poll status to observe completion.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "name": "<name>"
    },
    "name": "pause_pipeline"
  }
}

Input Schema

NameRequiredDescriptionDefault
nameYes

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.5/5.0
Behavior3/5

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

The annotations already declare non-read-only, destructive, non-idempotent, open-world behavior. The description adds genuine value beyond them by revealing that the call is asynchronous ('request' + poll to observe completion), which an agent must know to avoid treating the return as final. It does not explain the destructive impact on in-flight batches or any permission requirements, so it remains partial.

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?

Two short sentences, front-loaded with the action and followed by the essential follow-up step. Every clause carries information an agent needs.

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

Completeness5/5

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

Down-weighted dimension: with an output schema present, return values need not be explained. The remaining gap is behavioral (destructive impact, permission/async semantics depth) which overlaps the transparency score.

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

Parameters2/5

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

Schema description coverage is 0% and the single required parameter 'name' is never mentioned in the description. The agent gets no hint about whether 'name' is the pipeline name, an ID, or a fully qualified identifier, nor any link between it and the 'running pipeline' being paused.

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

Purpose4/5

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

Clear specific verb + resource ('pause of a running pipeline') and it implicitly pairs against the sibling resume_pipeline. It stops short of naming that sibling or scoping which pipelines qualify, so it is clear but not fully differentiated.

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?

'Request pause of a running pipeline' implies the precondition that the pipeline must be running, and 'Poll status to observe completion' points at the get_pipeline_status sibling. However, there is no explicit when-not guidance (e.g., what to do for a paused/stopped pipeline) and the routing advice is indirect.

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