Skip to main content
Glama
Sign In
opentakeoff-mcp

opentakeoff-mcp

by Kentucky-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

assistant_open

Open a private OpenTakeoff Assistant window so a user can chat from inside the canvas, returning a one-time pairing link and 6-letter code to connect and start listening.

Instructions

Open the OpenTakeoff Assistant window: the person can then talk to YOU from inside the OpenTakeoff canvas (opentakeoff.kentucky-ai.com) instead of only here. Starts a private link on 127.0.0.1 and returns a one-time pairing code and a link. Give the person the link (or the 6-letter code to type into the canvas's Assistant window), then call assistant_listen and keep calling it: each message they type arrives as its result; do the work with the other tools, answer with assistant_say, then listen again. Call it when the person asks for the OpenTakeoff assistant/window, or says "listen" after a pause.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "assistant_open"
  }
}

Input Schema

NameRequiredDescriptionDefault

No arguments

Output Schema

NameRequiredDescriptionDefault
codeYesOne-time pairing code the person types into the canvas's Assistant window (empty when already paired)
linkYesOpens the canvas and pairs automatically — give this to the person
nextYesWhat to tell the person, then what to call
portYes127.0.0.1 port the window connects to
powered_byYes
already_pairedYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.1.31

TDQS

A4.6/5.0
Behavior4/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 well: it discloses that a private link is started on 127.0.0.1, that the pairing code is one-time, and that the tool is only the entry point to a listen/say loop. It stops short of stating what happens if a window is already open, whether repeated calls create new codes, or how failures surface.

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-loads the action, then the mechanism, then the workflow, then the trigger conditions — a sensible progression with no filler. It is dense and long for a zero-parameter tool, but every sentence contributes either behavior or orchestration 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?

An output schema exists, yet the description still explains the returned code and link in usable terms and closes the loop by naming the follow-up calls. For a session-initiating tool with no parameters, an agent has everything needed to call it and continue correctly.

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?

The tool takes zero parameters, so the baseline is 4. The description adds only return-value information (a `code` and a `link`), which is not required for invocation but is consistent with the empty schema.

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?

Names a specific verb and resource ("Open the OpenTakeoff Assistant window") and immediately scopes what that means: the person talks to the agent from inside the OpenTakeoff canvas rather than in the current chat. It is clearly distinct from siblings assistant_listen and assistant_say, which the description positions as the follow-on steps.

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 triggers ("when the person asks for the OpenTakeoff assistant/window, or says 'listen' after a pause") and a precise post-call protocol: hand over the link or 6-letter code, then call assistant_listen and keep looping with assistant_say. Alternatives and sequencing are fully spelled out.

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

Deploy Server

Other Tools