Skip to main content
Glama

Connect to Unl

connect_to_unl
Read-onlyIdempotent

Where the person left off, from their own saved work: what they were working on, what they already decided, and what is next. Unl is already on without this call — ask_unl serves their decisions on any turn by itself — so call this when they ask where they left off, what they were working on or already decided, or to carry on with their project (and when they say 'connect to unl', which means the same). Their account comes from the authenticated session; there is no workspace argument. The optional venture argument is a project the person NAMED in their own words ('in inparticular…' → venture:'inparticular'; 'free space' → venture:'free space'). Omit it otherwise: with one project Unl uses it; with several, Unl reads which project each turn is about from what it says, so nobody declares or switches. Never choose one yourself: what you pass is only what they named. Pass the session token back on later calls. An empty account returns the first-run welcome; otherwise the next piece of work in the order they set, with what governs it. Returns facts from their saved work for you to reflect back in your own words; it is read-only and never tells you how to reason. If nothing is queued it says so plainly — do not invent a next step, because an invented step puts your priority in the place of the order they set.

Input Schema

NameRequiredDescriptionDefault
sessionNoThe continuation token from a PREVIOUS [unl-session: …] line, echoed verbatim, so this connect pins the venture on the SAME session your later calls carry. Omit on the first call of a conversation — unl mints one and returns it.
ventureNoA project the HUMAN named, verbatim, in their own words ('in inparticular…' → 'inparticular'). Pass 'free space' when they ask for it. OMIT it otherwise: with one project Unl uses it, with several it asks the human which. NEVER pick for them — a project picked for someone is unl deciding whose world this is — and never pass a venture they did not say.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / venture / description
      Previous value: -"A project the HUMAN named, verbatim, in their own words ('in inparticular…' → 'inparticular'). Pass 'free space' when they ask for it. OMIT it otherwise: with one project Unl uses it, with several it asks the human which. NEVER pick for them — a project picked for someone is unl deciding whose world this is (af332efa) — and never pass a venture they did not say."New value: +"A project the HUMAN named, verbatim, in their own words ('in inparticular…' → 'inparticular'). Pass 'free space' when they ask for it. OMIT it otherwise: with one project Unl uses it, with several it asks the human which. NEVER pick for them — a project picked for someone is unl deciding whose world this is — and never pass a venture they did not say."
  2. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already cover readOnlyHint/idempotentHint/destructiveHint, but the description adds substantive behavior: account derives from the authenticated session, an empty account returns the first-run welcome, an empty queue 'says so plainly', and the returned facts must be reflected in the agent's own words. It even explains the failure mode of inventing a next step, which is far beyond what the annotations convey.

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?

Purpose and trigger are front-loaded, but the prose is long and repetitive: the 'what they were working on / already decided' idea recurs, and 'Never choose one yourself: what you pass is only what they named' restates the schema's own warning verbatim. The closing clause about priority is rhetorical filler rather than operational 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?

For a zero-required-param, read-only tool with no output schema, the description covers everything an agent needs: no workspace argument, session token handling, empty-account and empty-queue behavior, and how to treat the returned facts. Nothing material is left to inference.

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 100% schema coverage the baseline is 3, but the description adds real meaning: it clarifies that `venture` must be what the person literally named ('in inparticular…' → venture:'inparticular'), and repeatedly warns never to choose a venture for them, and to pass `session` back on later calls. The shorthand-to-value mapping goes beyond the schema text.

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+resource with scope: returns 'where the person left off, from their own saved work' – what they were working on, decided, and what is next. It explicitly separates itself from the sibling ask_unl ('Unl is already on without this call — ask_unl serves their decisions... by itself'), so an agent can route without opening either 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 trigger conditions ('call this when they ask where they left off, what they were working on or already decided, or to carry on with their project') and names the alternative (ask_unl) with the reason it is not needed here. Includes the literal phrase 'connect to unl' as a synonym trigger.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.