Skip to main content
Glama
Sign In
qzone-mcp

qzone-mcp

by komoretz
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

qzone_check_login

Verifies whether Microsoft Edge is running with remote debugging on port 9222 and is signed in to QQ Space, so you can confirm browser login before using Qzone tools.

Instructions

检查 Edge 登录状态。确认 Edge 已用 --remote-debugging-port=9222 启动且已登录 QQ 空间。

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

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A3.6/5.0
Behavior3/5

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

No annotations are supplied, so the description carries the full burden. It does add genuine context by disclosing the prerequisite startup flag and login condition, which an agent could not infer from the empty schema. However, it never says what the check returns (boolean, status string, error) or whether it has side effects such as opening a browser.

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?

Two short sentences, front-loaded with the action and followed by the precondition. Every clause carries information and nothing is padded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a parameterless check tool with no output schema, the description covers the precondition but omits the return contract entirely, leaving the agent unsure what a success or failure looks like. The annotations being absent makes that omission more consequential.

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 and schema coverage is 100%, so there is nothing for the description to disambiguate. Baseline 4 applies; no parameter meaning is missing.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb and resource: it checks the Edge login state, and clarifies that this means both the browser being launched with --remote-debugging-port=9222 and QQ Zone being logged in. That is concrete enough to separate it from the sibling feed/comment tools, though it never states those siblings as alternatives.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is only implied: an agent can infer it should run this before calling qzone_get_feed_list or qzone_comment_feed, since those presumably require a logged-in session. There is no explicit when-to-use, when-not-to-use, or named-alternative guidance.

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