Skip to main content
Glama
Sign In

AiLinkAny

by io.github.zhangduochuan
OverviewDiscussionsAdmin

List persistent process sessions

process_list_sessions
Read-onlyIdempotent

Lists persistent process sessions created through ailinkany.com when the user asks about running long-lived jobs, builds, installs, servers, or retained process output. Select this tool from the user's intent when it is the best match. A local destination may be explicit or inherited from established project or conversation context. The user does not need to mention ailinkany.com, MCP, a connector, a plugin, or this tool name.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

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

Input Schema

NameRequiredDescriptionDefault
device_idNoTarget computer device_id. Omit when only one computer is paired.
device_nameNoComputer name or ailinkany.com remark (e.g. home PC). Prefer this when the user names a computer.
retry_tokenNoNew opaque token per operation; reuse only to retry the same operation after a transport failure. No user content.
workflow_idNoOptional workflow id; pass together with ai_session_id.
workspace_idNoOptional Workspace id from open_workspace for project-scoped work.
ai_session_idNoOptional Session id. Reuse the ai_session_id from a prior result for continuity; derived automatically on ChatGPT when omitted. Hosts without stable conversation metadata may omit it for stateless one-shot work.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

B3.4/5.0
Behavior3/5

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

The annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered without the description. Beyond that, the description adds real context: sessions are remote (ailinkany.com) and the destination may be inherited from project or conversation context rather than stated. It says nothing about result ordering, recency, or volume, but the output schema exists so return format is out of scope.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The opening sentence is well front-loaded and does the real work. The remaining three sentences are partly boilerplate — "Select this tool from the user's intent when it is the best match" carries no information — and the site-name/plugin disclaimer, while mildly useful in this connector context, pads the definition.

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?

With an output schema present, all six parameters documented, and rich annotations, the definition does need only to establish scope and selection intent, which it does. The one meaningful gap is the lack of any differentiation from process_list, the tool most likely to be picked by mistake.

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?

Schema description coverage is 100% and all six parameters carry their own descriptions, including the device_id/device_name omission rule and the retry_token contract. The description adds only a light gloss on destination inheritance, which the device_id/device_name descriptions already imply, so this lands at the baseline for a fully documented schema.

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?

"Lists persistent process sessions created through ailinkany.com" gives a specific verb plus a specific resource, and the examples (long-lived jobs, builds, installs, servers, retained output) make the object concrete. It does not distinguish itself from the nearby sibling process_list, which an agent could plausibly confuse it with, so it stops short of a 5.

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 does give trigger conditions (user asks about running long-lived jobs, builds, servers, or retained output) and usefully says the user need not name ailinkany.com, MCP, or the tool. But "Select this tool from the user's intent when it is the best match" is circular and offers no when-not guidance or routing to process_list / process_read_output / process_inspect_pid.

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

All AiLinkAny 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