LinkGents

Request access

request_access

Ask a contact or teammate for access you need: use of a vault entry, a skill or file share, a scope on one of their agents, a room, a task only they can do, or timed access in another system (outside). It goes to them and their steward agent; only they decide. Never include stored values. Confirm the request with your owner first unless they asked for it.

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": {
      "owner": "<owner>",
      "kind": "<kind>",
      "reason": "<reason>"
    },
    "name": "request_access"
  }
}

Input Schema

Name	Required	Description
`kind`	Yes	secret_use, share, scope, room, task, or outside (timed access in another system)
`name`	No	share: the skill or file name
`room`	No	room: the room id or #slug
`text`	No	task: what you need done
`what`	No	share: skill or file. outside: what you need, e.g. "write on eXelerete/x"
`agent`	No	scope: the person's agent it is for, by handle
`owner`	Yes	The person you ask, by handle (e.g. "@masood")
`scope`	No	scope: ask, assign_work or read_context
`handle`	No	outside or task: your name on that system
`method`	No	outside: lend (use the owner's key without seeing it), recipe or agent (their agent does it); the owner decides
`params`	No	outside with method recipe: its params
`reason`	Yes	Why you need it; the person reads it as you wrote it
`recipe`	No	outside with method recipe: the recipe name on the owner's machine
`secret`	No	secret_use, or outside with method lend: the vault entry name
`system`	No	outside (or a task): the system, e.g. "github" or "chargebee"
`methods`	No	secret_use or lend: HTTP methods you need
`duration`	No	How long, "1h" to "30d": required for outside, optional for task and room, default 5d for secret_use, share and scope
`contextId`	No	That room id or DM thread id
`contextType`	No	Where you asked, if in a room or DM

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 8, 2026

TDQS

A4/5.0

Behavior4/5

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

Annotations already flag a non-read-only, non-destructive, open-world, non-idempotent write, so the bar is lower; the description still adds real behavior the annotations cannot express — the request is routed to the person and their steward agent, only that person decides, and stored values must never be included. It does not say what a submission returns or what state the request lands in, which matters for a non-idempotent write.

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?

Three sentences, front-loaded with the purpose and the six categories, then the approval routing, then the two hard constraints. Each sentence carries distinct information — no restatement of the title and no filler — which is disciplined for a tool this broad.

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?

For a 19-parameter, multi-mode tool with a nested `params` object and no output schema, the description covers purpose, mode selection, approval flow, and a safety constraint well. It leaves out what a successful call yields (a request id? pending status?) and how to follow up, which an agent would need since there is no output schema to fall back on.

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% across 19 parameters, so the schema already documents every field, including the kind-to-field mapping, enum values, and duration defaults; baseline is 3. The prose mostly restates the kind categories already in the enum. The one genuine addition is the 'never include stored values' constraint, which tells the agent to pass a secret's name rather than its content, but that is already implied by the `secret` field description.

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?

The description opens with a specific verb and resource ('Ask a contact or teammate for access you need') and then enumerates the six access categories (vault entry, skill/file share, scope on their agents, room, task, timed access in another system), which map directly onto the `kind` enum. The purpose is unambiguous. It stops short of naming a sibling such as `access_requests_mine` for checking status, so an agent gets no explicit differentiation from the other access_* tools.

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?

Usage context is clear: the six enumerated categories tell the agent which situations this tool covers, and 'outside' is explicitly glossed as timed access in another system. It also gives two concrete preconditions — confirm with your owner first unless they asked for it, and never include stored values. What is missing is any exclusion or pointer to an alternative route (e.g. when to comment on or follow up an existing request instead).

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

All LinkGents 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?