Skip to main content
Glama

dialogbrain

by io.github.saloprj
OverviewDiscussionsAdmin

present_tab

Read-onlyIdempotent

Put one of the agent's browser tabs on the live call's screen-share. Pass the page_id you got from browser.open. Only usable while the agent is in an active voice call. THIS IS THE ONLY WAY TO CHANGE WHAT THE ROOM SEES — scrolling or pressing keys changes the page, never which tab is shared. The shared tab stays the active share until you call present_tab with a different page_id, call present_stop to take it down, close the tab via browser.close, or the call ends. Returns the page_id, url and title actually on screen; check them before telling anyone what they are looking at, and use present_status to re-check later.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
page_idYespage_id returned by browser.open for the tab you want to share. Must be a tab still open in the agent's browser context.
in_workspaceNoRun this one call in this workspace id instead of the session's. Nothing is stored; other sessions are not affected.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / in_workspace
      Added value: +{
+  "description": "Run this one call in this workspace id instead of the session's. Nothing is stored; other sessions are not affected.",
+  "type": "integer"
+}
  2. Added
  3. Removed
  4. Added

TDQS

A4.6/5.0
Behavior5/5

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

Annotations cover the safety profile (readOnly, idempotent, non-destructive), and the description adds genuinely extra context: the share persists until a different page_id is passed, present_stop is called, the tab is closed, or the call ends. It also warns to verify the returned url/title before describing the screen to others. No contradiction with the readOnly/high-level hints, since this mutates the call presentation rather than stored data.

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-loaded and dense, with the critical constraint (only in an active call) and the anti-pattern (scrolling doesn't change the share) called out emphatically. Slightly long, but nearly every clause carries operational information rather than filler.

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, and the description compensates by describing what is returned (page_id, url, title actually on screen) and how to re-verify state via present_status. Combined with the lifecycle rules for the share, an agent has everything needed to call it correctly.

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 page_id's origin and the in_workspace override are already documented in the schema. The description restates the browser.open source but adds no syntax, format, or semantics beyond it, so the baseline 3 applies.

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?

Opens with a concrete verb+resource+destination: 'Put one of the agent's browser tabs on the live call's screen-share.' An agent can immediately distinguish this from siblings like present_stop, present_status, and the browser_* tab tools.

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?

States the prerequisite ('Only usable while the agent is in an active voice call'), the source of the required argument (page_id from browser.open), and the routing rule against the tempting alternatives: scrolling or key presses change the page, never the shared tab. It also names present_stop as the way to take the share down and present_status for re-checking.

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

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