Skip to main content
Glama
Sign In

Dock

by ai.trydock
OverviewDiscussionsAdmin

request_connection

Ask your owner to connect a third-party app (Gmail, Slack, Notion, Linear...) so you can use its tools. It does NOT connect anything and does NOT give you access — it reports the state and tells you what to ask for. Call it when a task needs an app you cannot currently reach, then tell the user plainly that you have asked. Do not call it repeatedly for the same app in one conversation; one ask is enough, and the answer is theirs to give. If your owner says no to an app, call it once with owner_declined: true so the no is remembered; asks for an app they declined are refused for 30 days, unless they connect it themselves or ask you for it. TWO DIFFERENT STATES, and they need different asks. If it comes back connection_required: true, the app is not connected at all and only your owner can connect it. If it comes back already_connected: true with you_have_access: false, the app IS connected and simply is not shared with you — post the ask_with_marker string from the response on its own line and your owner gets a one-tap Approve card in the chat. ⛔ In neither case ask for that app's API key instead: a vaulted key is a different thing, it hands you a raw credential, and it steps around the per-agent access your owner controls.

Input Schema

NameRequiredDescriptionDefault
reasonNoOne short sentence on why you need it, shown to the user on the card. Be concrete: 'to read the thread you asked me to summarise' beats 'to help you'.
toolkit_slugYesThe app to request, e.g. 'gmail', 'slack', 'notion', 'linear'. Must be one Dock offers; anything else is refused.
owner_declinedNoSet true ONLY to record that your owner said no to this app (in chat: 'we won't use it', 'stop asking'). Shows no card; it stops you and their other agents from asking for it again for 30 days. Call it once, as soon as they say no.
owner_requestedNoSet true ONLY when your owner's own latest message asks you to set this app up. It lifts a recorded 'no'. Never set it on your own initiative.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / owner_declined
      Added value: +{
+  "description": "Set true ONLY to record that your owner said no to this app (in chat: 'we won't use it', 'stop asking'). Shows no card; it stops you and their other agents from asking for it again for 30 days. Call it once, as soon as they say no.",
+  "type": "boolean"
+}
    • addedInput schema / properties / owner_requested
      Added value: +{
+  "description": "Set true ONLY when your owner's own latest message asks you to set this app up. It lifts a recorded 'no'. Never set it on your own initiative.",
+  "type": "boolean"
+}
  2. Added

TDQS

A4.8/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so: it discloses that the tool connects nothing, that the response carries state flags plus an ask_with_marker string the agent must post on its own line to trigger an Approve card, the 30-day refusal cooldown after a decline, and that declines show no card. These are exactly the non-obvious behaviors an agent would otherwise get wrong.

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?

Dense and front-loaded: purpose, then when to call, then the two states, then the API-key prohibition, with caps and markers segmenting the flow. It is a single long block rather than broken into distinct sections, and the state-handling detail could be tightened, but essentially every sentence carries non-redundant guidance.

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

Completeness5/5

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

No output schema exists, yet the description names the key response fields (connection_required, already_connected, you_have_access, ask_with_marker) and what to do with each, which is precisely the missing coverage. For a 4-parameter tool with no annotations, nothing an agent needs to call or act on the result is left out.

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 still adds operational meaning by tying owner_declined to the real-world event ('if your owner says no to an app, call it once') and its 30-day consequence, and by mapping owner_requested to the lift-a-no condition. The reason and toolkit_slug semantics are left to the already-thorough schema descriptions.

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 ('Ask your owner to connect a third-party app') and immediately clarifies the negative scope ('does NOT connect anything and does NOT give you access — it reports the state'). The two-state model (connection_required vs already_connected) plus the explicit contrast with vaulted API keys distinguishes it cleanly from siblings like pull_capability and list_api_keys.

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 trigger conditions ('Call it when a task needs an app you cannot currently reach'), explicit anti-patterns ('Do not call it repeatedly for the same app in one conversation'), routing rules for the two response states, and a hard prohibition ('⛔ In neither case ask for that app's API key instead'). Timing rules for owner_declined ('call it once, as soon as they say no') and owner_requested ('Never set it on your own initiative') are spelled out.

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

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