Skip to main content
Glama
Sign In

Desearch

by io.github.Desearch-ai
OverviewDiscussionsAdmin

Pause Company Search

company-search-pause
Idempotent

Pause a Company Search or Company Enrich task and return its updated status. Free: it charges and refunds nothing. A queued task pauses at once; a running one finishes its current batch first (status pausing, then paused). Pausing loses no data: the companies delivered so far stay readable with company-search-status, and the task keeps its progress. Billing does not change: the reservation made when the task started stays reserved while paused and is settled only when the task ends. Undo it with company-search-resume, which continues from where the task stopped with no new charge. Limit: a task paused for more than 7 days is cancelled by the API and can no longer be resumed; you then pay only for the companies already delivered, the rest of the reservation is returned, and the companies delivered stay readable for 30 days.

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": {
      "task_id": "<task_id>"
    },
    "name": "company-search-pause"
  }
}

Input Schema

NameRequiredDescriptionDefault
task_idYestask_id returned by company-search or company-enrich, example: '5b33f3ee-168b-4780-9c8e-63a626781872'. A People Search task_id is not found here.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.5/5.0
Behavior5/5

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

Beyond annotations, the description discloses important behavior: pausing is free, queued tasks pause immediately, running tasks finish their current batch, billing reservations stay reserved, no delivered data is lost, and paused tasks are auto-cancelled after 7 days. These details materially help an agent understand side effects and billing consequences.

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 front-loaded with the core action and then proceeds through only relevant behavioral details: charging, queued/running behavior, data retention, billing, undo, and expiration. Despite its length, every sentence adds operationally useful information.

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?

Given the complex billing and task-state behavior, the description covers the essential details an agent needs before invoking the tool, including status transitions, data safety, billing reservation behavior, resume path, and 7-day cancellation limit. With no output schema, it still adequately states that the tool returns the updated status.

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?

There is one parameter and the schema description coverage is 100%, including UUID format and a note that People Search task IDs are not valid here. The description does not add further task_id semantics beyond what the schema already provides, so the baseline 3 applies.

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 states a precise verb and resource: pause a Company Search or Company Enrich task and return its updated status. It clearly distinguishes the operation from sibling tools such as company-search-resume and company-search-status by naming them for the undo and read paths.

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?

It explains when to use the tool, what happens for queued versus running tasks, and explicitly points to company-search-resume for undoing and company-search-status for reading delivered companies. It does not directly contrast with company-search-cancel or warn against pausing people-search tasks, so it falls short of fully explicit when-not guidance.

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

All Desearch toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources