Skip to main content
Glama
Sign In

AiLinkAny

by io.github.zhangduochuan
OverviewDiscussionsAdmin

Execute a user-authorized Git integration review

project_execute_reviewed_integration
Idempotent

Execute exactly one prepared Git integration review, decided by the calling AI without a user authorization step. Uses only the immutable SHAs and merged tree recorded at prepare time (never re-resolves branch names) and creates a NEW isolated local candidate branch agent/p7-integration-* chosen by the Host. Never moves the target branch, never checks out, never changes working files, never pushes and never deploys; remote writeback stays disabled. A wrong review_digest returns PROJECT_INTEGRATION_REVIEW_MISMATCH; replay with the same execution_request_id returns ALREADY_CONSUMED; a different execution_request_id after consumption returns PROJECT_INTEGRATION_ALREADY_CONSUMED. 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>",
      "task_id": "<task_id>",
      "generation": "<generation>",
      "review_id": "<review_id>",
      "expected_review_digest": "<expected_review_digest>"
    },
    "name": "project_execute_reviewed_integration"
  }
}

Input Schema

NameRequiredDescriptionDefault
task_idYesOwn live task id that prepared the review.
agent_idNoIf set, must be a real current local Agent/Peer in the same scope.
device_idNoTarget computer device_id. Omit when only one computer is paired.
review_idYesreview_id returned by project_prepare_integration_review.
generationYesSame fencing generation used at prepare time.
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_idYesAuthorized Workspace returned by open_workspace; the Host derives its Git repository.
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.
execution_request_idNoOptional idempotency key; defaults to one derived from review_id. Reuse it only to replay the same execution.
expected_review_digestYesreview_digest returned by project_prepare_integration_review.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4/5.0
Behavior3/5

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

The description goes well beyond the annotations: it enumerates what is never touched (target branch, checkout, working files, push, deploy), notes remote writeback stays disabled, and names three distinct failure codes (MISMATCH, ALREADY_CONSUMED, ALREADY_CONSUMED for a new request id). It is consistent with readOnlyHint=false / destructiveHint=false since a new isolated candidate branch is created but nothing existing is disturbed. However, the final three sentences are generic routing boilerplate ('Select this tool from the user's intent when it is the best match', the ailinkany.com disclaimer) that add words rather than behavioral information, and the description never states the authorization expectations implied by the title 'user-authorized', leaving a notable gap on a mutation 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 invariants and error codes are front-loaded and dense, which is good, but the closing routing sentences ('Select this tool from the user's intent when it is the best match', 'The user does not need to mention ailinkany.com, MCP, a connector...') are generic boilerplate that would fit any tool and dilute an otherwise precise 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, four annotations, and 100% schema coverage, the description supplies what structured fields cannot: the prepare-time SHA freeze, the no-side-effects guarantee, and the replay/error contract. The one loose end is the tension between 'decided by the calling AI without a user authorization step' and the title's 'user-authorized', which an agent could misread as a consent requirement.

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; the description earns one more by tying expected_review_digest to a concrete failure code and execution_request_id to replay/ALREADY_CONSUMED semantics, and by explaining that generation and the SHAs are frozen at prepare time. The remaining params (agent_id, device_name, workflow_id, ai_session_id) are left entirely to the schema, so it is not a full 5.

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 (execute) and a narrowly scoped resource (exactly one prepared Git integration review), and the follow-on constraints ('uses only the immutable SHAs and merged tree recorded at prepare time') distinguish it cleanly from the sibling project_prepare_integration_review. An agent can tell which of the two lifecycle halves this covers without inspecting the schema.

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 states the precondition implied by 'prepared' review plus the 'from the user's intent' routing rule and that the user need not name the connector, which is real selection guidance. What is missing is an explicit when-not rule pointing back at prepare or at a re-prepare path after a consumed review, so an agent must infer that recovery step.

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