Skip to main content
Glama

freedom-mcp

by com.getfreedomos
OverviewDiscussionsAdmin

Request connector

request_connector
Destructive

Climb the door ladder for a needed service: bind this company's connector, offer reuse of an account the operator already admins on another FreedomOS company ("use that account?"), use a FreedomOS-native door when we can, then a vetted/rented connect card. Use when a goal needs a service that is not yet bound here. Provide the name from search_connector_registry and a short reason. Does not connect by itself and never spends money. Never treat not-connected as done.

[sensitive-tier, initiates a multi-step agent process — company managers (executive/gm) run this without a card. Other members ask once; a from-now-on approval makes future calls seamless. Connecting a connector still needs the OAuth/connect card (request≠grant). Call it on the first clear ask — do not re-ask in chat.]

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
scopeNoWho may use the connection once it is live. "company" (default) = everyone in this company. "personal" = "Just me": only the person who signs in (their chats, MCP key and bots they host) — e.g. a personal inbox. The approver can still change it on the card.
reasonNoWhy you need it — the capability gap it closes (e.g. "run the KDP book ad campaign").
companyIdYesFreedomOS company id to act within (you must be a member). Required for company-scoped tools.
connectorYesName of the connector to request (from search_connector_registry, e.g. "Amazon Ads").

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / scope
      Added value: +{
+  "description": "Who may use the connection once it is live. \"company\" (default) = everyone in this company. \"personal\" = \"Just me\": only the person who signs in (their chats, MCP key and bots they host) — e.g. a personal inbox. The approver can still change it on the card.",
+  "enum": [
+    "company",
+    "personal"
+  ],
+  "type": "string"
+}
  2. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the annotations, the description discloses that the tool does not connect by itself, never spends money, initiates a multi-step sensitive process, and that request does not equal grant. It also clarifies approval behavior for managers vs other members, which is critical context the annotations alone do not provide.

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?

The description is dense and front-loaded with the core purpose and usage trigger, and every sentence carries meaningful guidance. It is somewhat verbose due to the 'door ladder' metaphor and bracketed policy block, but those details justify their place for a sensitive multi-step tool.

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?

Given the tool's complexity, the description covers when to use it, what inputs to provide, what it does not do, approval requirements, and the need to treat a request as distinct from grant. Even without an output schema, the agent has sufficient context to invoke it appropriately.

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 100%, so the parameters are already fully documented. The description adds minor reinforcement (use a name from search_connector_registry, provide a short reason) but does not materially extend the semantic meaning beyond the 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?

The description clearly states the tool requests a connector/service when one is not yet bound, and explicitly distinguishes it from actual connection ('Does not connect by itself'). It names the source for the connector (search_connector_registry) and the required reason, giving the agent a precise action and resource.

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?

It gives explicit trigger conditions: 'Use when a goal needs a service that is not yet bound here' and instructs to provide the registry name and reason. It also states when not to call ('do not re-ask in chat') and offers a decision ladder (bind, reuse, native door, card) that routes the agent away from premature or repeated requests.

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

All freedom-mcp 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