AiLinkAny

Claim files for a coordinated project task

project_task_claim

Atomically claim relative project file scopes in the local Host ledger, across separate AI Sessions and Workspace ids sharing the same account/device/canonical project directory. Overlaps never block: the claim succeeds and the result carries overlaps + advice; decide yourself (own git worktree, read before write). May refresh one's own live task with task_id+generation. This is not a filesystem access grant; Shell and OS hard enforcement are a separate stage. 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

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": {
      "workspace_id": "<workspace_id>",
      "title": "<title>",
      "files": "<files>"
    },
    "name": "project_task_claim"
  }
}

Input Schema

Name	Required	Description
`files`	Yes	Relative project file or directory scopes, e.g. cloud/src/mcp.js.
`title`	Yes
`task_id`	No	Own task id to update claimed scope; must also supply its generation.
`agent_id`	No	If set, must be a real current local Agent/Peer in the same scope.
`lease_ms`	No
`device_id`	No	Target computer device_id. Omit when only one computer is paired.
`generation`	No	Fencing generation returned by own prior claim.
`device_name`	No	Computer name or ailinkany.com remark (e.g. home PC). Prefer this when the user names a computer.
`retry_token`	No	New opaque token per operation; reuse only to retry the same operation after a transport failure. No user content.
`workflow_id`	No	Optional workflow id; pass together with ai_session_id.
`dependencies`	No
`workspace_id`	Yes
`ai_session_id`	No	Optional 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

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 9, 2026

TDQS

A3.7/5.0

Behavior4/5

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

Annotations already declare the safety profile (readOnly=false, destructive=false, idempotent=false), and the description adds genuinely new behavior: claims are atomic, overlapping claims succeed rather than block, and the result carries overlaps plus advice. It also pre-empts a dangerous misreading by stating this grants no filesystem or shell enforcement. It stops short of explaining lease expiry/lease_ms defaults or what happens to a claim after the session ends, which is the main behavioral gap for a leasing tool.

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 core semantics are front-loaded well in the first two sentences, and the 'not a filesystem access grant' caveat earns its place. The closing three sentences about user intent, inherited destinations, and not needing to mention ailinkany.com/MCP/the tool name are boilerplate that dilutes the definition and should be trimmed.

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

Completeness3/5

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

An output schema exists, so return shape needn't be explained, and the description still usefully flags that results carry overlaps and advice. For a 13-parameter, non-idempotent coordination tool, though, it omits lease lifetime and expiry semantics, re-claim/refresh failure behavior, and how dependencies interact with claims, leaving real gaps an agent would hit on invocation.

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 coverage is 69%, so several parameters are already documented inline (files, task_id, generation, retry_token, device_name, ai_session_id). The description adds meaning for the task_id+generation pair as a fencing/refresh mechanism and clarifies that scopes are relative, but it says nothing about lease_ms duration, dependencies, agent_id, or the device_id vs device_name choice beyond what the schema already states. Baseline 3 is appropriate given partial schema coverage.

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 first sentence names a specific verb (atomically claim) and resource (relative project file scopes in the local Host ledger) and scopes it across Sessions and Workspace ids. It also explicitly distinguishes the tool from filesystem access ('This is not a filesystem access grant'), so an agent can tell it apart from filesystem_* and project_task_update without opening a 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?

Usage context is present but mostly implied: it explains that overlaps never block and the agent must decide itself (own git worktree, read before write), and that task_id+generation refreshes one's own live task. However, it never names the alternative sibling (project_task_update, project_coordination_status) or states a clean when-not rule; the sentence 'Select this tool from the user's intent when it is the best match' is generic filler rather than routing guidance.

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

All AiLinkAny tools Inspect

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

Need Help?