Skip to main content
Glama

Pause a listening search

pause_saved_search
Idempotent

Stop checking a saved search (id from list_saved_searches) without deleting it.

Input Schema

NameRequiredDescriptionDefault
idYesRequired for pause, resume and delete.
workspaceIdNoWorkspace to work on (an id from list_workspaces). Not needed when this connection is tied to one workspace, or when you pass an account: the account's workspace is used.
idempotencyKeyNoOptional. A unique id for this action (16-128 chars: letters, digits, _ : . -). If you are unsure whether a call went through (timeout, network error), repeat it with the SAME idempotencyKey and the same arguments: you get the original result and nothing is done twice.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4/5.0
Behavior3/5

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

Annotations already declare destructiveHint=false and idempotentHint=true, so the safety profile is covered. The description's 'without deleting it' merely restates the non-destructive annotation, and it adds nothing about the resulting search state or how to undo the pause.

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?

A single front-loaded sentence with a parenthetical that earns its place by locating the required id. No filler, no redundancy.

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 non-destructive, idempotent mutation whose annotations and schema already carry the safety and parameter detail, the description covers what the tool does and what it does not do. The only gap is that it does not mention the complementary resume_saved_search sibling or the state left behind.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description goes one step further by naming where the required id comes from (list_saved_searches), which the schema itself does not state. It says nothing extra about workspaceId or idempotencyKey, which the schema already documents well.

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?

Names a specific verb+resource ('Stop checking a saved search') and immediately contrasts it with the destructive sibling ('without deleting it'), so an agent can distinguish it from delete_saved_search without opening either schema.

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?

It points the agent at list_saved_searches as the source of the required id, which is useful prerequisite guidance. However, it never states when to pause versus resume_saved_search or what condition should trigger a pause, so usage is only implied.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources