AiLinkAny

Add MCP server to local Gateway

mcp_manager_add_server

Adds one downstream MCP server to the target computer's AiLinkAny Registry through the same Manager Service used by the desktop UI. Read the current config_revision from mcp_gateway_list_servers first and pass it as expected_revision. Prefer enabled=false for a new server until mcp_manager_test_server succeeds, then enable it. environment and headers accept secret_ref values only; never place API keys, tokens, passwords, cookies, private keys, or other secret plaintext in this tool. 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": {
      "expected_revision": "<expected_revision>",
      "name": "<name>",
      "transport_type": "<transport_type>"
    },
    "name": "mcp_manager_add_server"
  }
}

Input Schema

Name	Required	Description
`url`	No
`args`	No
`name`	Yes
`command`	No
`enabled`	No	Defaults to true. Prefer false until the first test succeeds.
`headers`	No	Streamable HTTP header binding map: Header-Name -> secret_ref. Values are references, never secret plaintext.
`device_id`	No	Target computer device_id. Omit when only one computer is paired.
`server_id`	No	Optional stable server id. Omit to let the client generate one.
`device_name`	No	Computer name or ailinkany.com remark (e.g. home PC). Prefer this when the user names a computer.
`environment`	No	stdio environment binding map: ENV_NAME -> secret_ref. Values are references, never secret plaintext.
`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.
`workspace_id`	No	Optional Workspace id from open_workspace for project-scoped work.
`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.
`transport_type`	Yes
`expected_revision`	Yes	Exact config_revision most recently read from mcp_gateway_list_servers. On CONFIG_REVISION_CONFLICT, re-read before deciding whether to retry.
`working_directory`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 9, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare this is a non-read-only, non-destructive, non-idempotent write. The description adds real value beyond that: the optimistic-concurrency contract (expected_revision, CONFIG_REVISION_CONFLICT handling) and the hard constraint that environment/headers accept only secret_ref values, never plaintext secrets. It does not cover failure modes such as duplicate names or transport-specific validation, which keeps it from a 5.

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

Conciseness4/5

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

Front-loaded with the action and the revision/test workflow, which is the right ordering. The trailing sentences about intent matching and the user not needing to mention ailinkany.com, MCP, or the tool name are lower-value boilerplate that dilutes an otherwise tight 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?

An output schema exists, so return values need not be explained, and the description covers the revision-conflict and secret-handling behavior an agent must get right. The main omission is transport-specific parameter requirements for a 17-parameter tool with a transport_type enum.

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?

With 17 parameters and only 65% schema description coverage, the description compensates for the most consequential ones: expected_revision's source, enabled's default posture, and the secret_ref-only semantics of environment and headers. It does not clarify which parameters apply to stdio versus streamable_http (url vs command/args/working_directory), leaving a meaningful gap.

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?

States a specific verb and resource ('Adds one downstream MCP server to the target computer's AiLinkAny Registry') plus the mechanism ('through the same Manager Service used by the desktop UI'). This clearly separates it from mcp_manager_update_server, mcp_manager_remove_server, and mcp_manager_set_server_enabled without needing 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 Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit sequencing: read config_revision from mcp_gateway_list_servers first, pass it as expected_revision, and prefer enabled=false until mcp_manager_test_server succeeds before enabling. It names the sibling tools that form the workflow and states the intent-matching condition for selecting this tool.

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?