Skip to main content
Glama
Sign In

briq

by cloud.briq
OverviewDiscussionsAdmin

Publish a briq: its HTTPS URL, or a TCP endpoint

briq_expose
Destructive

Give a briq its HTTPS URL, on one port (https://-<4 random characters>., kept for the life of the briq). mode "private" opens only with the URL you get back: it carries a secret, briq turns away every request without it before it reaches the briq, and the browser keeps it as a cookie after the first visit. Use "private" whenever the person wants it private, protected or only for them; "public" is open to anyone on the internet. Visits to the URL count as use for its whole stack, so an exposed briq sleeps only when nobody uses it, and a visit to a sleeping one wakes it. A briq has one URL, on one port: its front door (the one a recipe names, or the only port in ports) is published at once; another port moves the URL there and restarts the machine (processes start over, files on disk are kept). Without mode, a URL that already exists keeps the mode it has, so moving a private URL never opens it; a first URL is public. rotate: true gives a private URL a new token, for when the link went somewhere it should not have: the URL stays, the old token stops working; a public URL has none to rotate. A briq declares at most 32 ports. Simplest: briq_run with expose. protocol other than "http" makes a TCP endpoint instead, for a client outside briq (psql, a BI tool, a laptop): -<10 random characters>.tcp. on the usual port of its protocol, TLS required. postgres (5432), mysql (3306), redis (6379), mongodb (27017), amqp (AMQPS 5671), bolt (Neo4j, 7687), grpc (6334). The database port of a recipe (briq_status lists them as databasePorts) answers with its full connection string, password included; another briq gets the address, to which you add its user and password. No token: the password is the gate, so mode does not apply, and the edge refuses a Postgres, Redis or MongoDB that lets anyone in. Only when the person wants to reach the service from outside: briqs of the stack reach it on its internal address already.

Input Schema

NameRequiredDescriptionDefault
briqYes
modeNo
portYes
rotateNoA new token for a private URL; the old one stops working
protocolNoWhat the port speaks: http (default) for an HTTPS URL, or a database protocol

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Beyond the annotations, it explains URL lifetime, token secrecy and cookie behavior, default mode inheritance, port-move restarts with process loss but disk retention, visit-based sleep/wake behavior, and rotation invalidation. These are substantial side effects and defaults that an agent needs before calling a destructive, open-world mutation.

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-loads the core operation, but it is long and uses several nested parentheticals. Most sentences carry useful behavioral or usage information, though the density makes it slower to parse than an ideal definition.

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 complex, destructive, open-world mutation with no output schema, it covers the important gaps: outputs in concept, default behavior, side effects, protocol-specific return values, and safety constraints. An agent would have enough context to choose parameters and anticipate consequences.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With only 40% schema description coverage, the description compensates heavily: it explains `mode` semantics and defaults, `rotate` invalidation, `protocol` mapping to TCP endpoint behavior, and `port` as the front door or moved port. The only lightly covered parameter is the briq identifier, whose pattern is already clear from the 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?

The description states a specific verb and resource: giving a briq an HTTPS URL or a TCP endpoint. It distinguishes the operation from the simpler sibling path by noting that `briq_run` with `expose` is the simplest route, while this tool handles explicit publishing and protocol selection.

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 explicitly states when to use `private` versus `public`, when to use a TCP endpoint, and when not to expose externally because stack-internal addresses already work. The alternative `briq_run` path is also named.

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

All briq toolsInspect
Try in Browser
Context Every Agent Can ShareAgents share what they learn, hand off work, and keep it when you switch models. Start with 5 GB free.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources