Skip to main content
Glama
Sign In
chat-export-server

chat-export-server

by svergio
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

platforms_status

Read-onlyIdempotent

Probe each provider's gate and limit status on the bound browser without sending a prompt, returning states like ok, rate_limit, busy, or auth_wall so you can choose a platform before asking.

Instructions

Probe gate/limit status per provider on the bound browser without sending a prompt. Returns state ok|rate_limit|busy|auth_wall|generating|composer_blocked|no_tab|offline|error plus code/kind/banner/retryable. Prefer before chat_ask when choosing a platform; set ensureTab:true to open a start tab before probing. Uses platform.host_state on open tabs; no_tab platforms include lastAlert only.

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": "platforms_status"
  }
}

Input Schema

NameRequiredDescriptionDefault
platformNoProbe one provider; omit to scan all enabled on the bound browser
ensureTabNoIf true, tabs_ensure before host_state when no tab is open (default false)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.0.7

TDQS

A4.7/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 goes well beyond that: it discloses the no-prompt side effect, the full state vocabulary, the accompanying code/kind/banner/retryable fields, that it relies on platform.host_state for open tabs, and that no_tab platforms return lastAlert only. That is exactly the read-path detail an agent needs to interpret results correctly.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Four sentences, each carrying distinct information: purpose, return contract, routing advice, and edge-case behavior. The purpose and the no-prompt constraint are front-loaded, and nothing is padded.

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?

With no output schema, the description compensates by enumerating every possible state plus the sibling fields returned alongside it. Combined with the no_tab caveat and the routing guidance, an agent has everything needed to call this and interpret the result.

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% and both parameter descriptions already explain the omit-to-scan-all default and the ensureTab/tabs_ensure sequencing, so the description largely restates structured data. The extra "open a start tab before probing" phrasing adds only marginal framing on top of 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?

States a specific verb and resource: "Probe gate/limit status per provider on the bound browser without sending a prompt." It explicitly contrasts itself with chat_ask, and the enumerated state values make the exact deliverable unambiguous.

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?

"Prefer before chat_ask when choosing a platform" names the alternative sibling and the condition that selects this tool over it. The ensureTab note gives a second concrete invocation rule, so an agent knows both when and how to reach for it.

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