Skip to main content
Glama

Ask JxBrowser Question

ask-jxbrowser-question
Read-only

Get documentation-based help with JxBrowser APIs, examples, integration, and troubleshooting. Ask one focused question when JxBrowser-specific information is needed. Each call is independent.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
questionYesOne focused JxBrowser question, usually 1–3 short sentences. Include only essential API names, version details, or a short error excerpt. Omit full files, long logs, and unrelated requirements.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
    • removedInput schema / additionalProperties
      Removed value: -false
    • changedInput schema / properties / question / description
      Previous value: -"The question or request about JxBrowser. Be specific and include relevant context like error messages, code snippets, or what the user is trying to achieve."New value: +"One focused JxBrowser question, usually 1–3 short sentences. Include only essential API names, version details, or a short error excerpt. Omit full files, long logs, and unrelated requirements."
    • addedInput schema / properties / question / minLength
      Added value: +1
  2. First observed

TDQS

A3.5/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds useful context beyond that — the tool is 'documentation-based' and each call is independent — but doesn't discuss limits such as whether the answer may be returned asynchronously, how much context it retains, or behavior for out-of-scope questions. With annotations present this is acceptable but not rich.

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?

Three short sentences with the core purpose front-loaded, followed by usage context and an independence note. Nothing is wasted, and it reads naturally at lookup time.

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

Completeness4/5

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

For a single-parameter, read-only Q&A tool with 100% schema coverage and annotations present, the description covers purpose, scope, and usage. The return value (a documentation-based answer) is reasonably self-evident without an output schema. The only minor gap is the lack of any pointer toward the sibling quickstart tool for overview needs.

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 description coverage is 100% and the schema already documents the parameter well ('One focused JxBrowser question, 1–3 short sentences… omit full files'). The description's 'one focused question' guidance duplicates the schema rather than adding new meaning, so the baseline 3 applies.

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 states a clear verb+resource ('Get documentation-based help with JxBrowser APIs, examples, integration, and troubleshooting') and is semantically distinct from the sibling get-quickstart-guide since it addresses questions rather than a static guide. However, it never explicitly names the sibling or contrasts itself, so differentiation is implicit rather than stated.

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?

'Ask one focused question when JxBrowser-specific information is needed' gives a clear usage context, and 'Each call is independent' is a useful operational hint. But it doesn't state when NOT to use this tool, nor does it mention the alternative (get-quickstart-guide) or any boundary between asking a question and fetching the quickstart.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources