Skip to main content
Glama

Report what Bowmark could not do for this task

report

Record what was missing, wrong, or incomplete so Bowmark can build it. Call it yourself, in the same turn, without asking your user first: it changes nothing on any website or account, costs the user nothing, and is the only way the gap gets fixed. Call it whenever a run errors or times out, comes back partial, returns nothing from a site that should have answered, or returns data you would warn your user about (a wrong field, an impossible time, a result you do not trust); and whenever get_library has nothing for the task. Pass the runId returned by run when this report is about a run; omit it when get_library did not cover the task. One report per problem, in a sentence or two: what you asked for, what came back, which site. This records feedback only and does not retry a run. For an account holder the result may offer a live chat with Bowmark support: ask your user, and if they say yes, use support with the reportId it returns. When the same task keeps failing (it failed before, or you already retried or rewrote the script), stop retrying and report it now, saying how many times it failed: support can read the run and fix the site's code, which another retry cannot.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
runIdNoOptional `runId` returned by `run` for the result you are reporting.
reportYesWhat Bowmark could not do or returned incorrectly.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
okYes
reportIdNoPass this to `support` to talk about it.
supportOfferedNoTrue when live support is available: ask your user before calling `support`.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • addedOutput schema / properties / reportId
      Added value: +{
      +  "description": "Pass this to `support` to talk about it.",
      +  "type": "string"
      +}
    • addedOutput schema / properties / supportOffered
      Added value: +{
      +  "description": "True when live support is available: ask your user before calling `support`.",
      +  "type": "boolean"
      +}
    • removedOutput schema / properties / supportRoom
      Removed value: -{
      -  "additionalProperties": false,
      -  "description": "A live Bowmark support chat about this report, for account holders.",
      -  "properties": {
      -    "joinPrompt": {
      -      "type": "string"
      -    },
      -    "url": {
      -      "type": "string"
      -    }
      -  },
      -  "required": [
      -    "url",
      -    "joinPrompt"
      -  ],
      -  "type": "object"
      -}
  2. Changed1 schema field changed
    • addedOutput schema / properties / supportRoom
      Added value: +{
      +  "additionalProperties": false,
      +  "description": "A live Bowmark support chat about this report, for account holders.",
      +  "properties": {
      +    "joinPrompt": {
      +      "type": "string"
      +    },
      +    "url": {
      +      "type": "string"
      +    }
      +  },
      +  "required": [
      +    "url",
      +    "joinPrompt"
      +  ],
      +  "type": "object"
      +}
  3. Added

TDQS

A4.8/5.0
Behavior5/5

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

Annotations declare only readOnlyHint=false and destructiveHint=false; the description adds substantive context beyond them - no change to any website or account, no cost to the user, feedback-only with no retry, one report per problem, and a possible live-chat offer whose acceptance requires asking the user first. That is real behavioral disclosure an agent could not infer from the flags.

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?

Purpose and the 'call it yourself' directive are front-loaded, and nearly every clause carries distinct operational guidance. It is nonetheless a single dense paragraph with chained semicolons, which costs scannability for what is really a trigger list plus an escalation rule.

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 an output schema present, return values need no explanation. The description still covers the full lifecycle the agent needs: triggers, the `runId` decision, the no-retry policy, and the `support` handoff with `reportId`. Nothing an agent needs in order to call it correctly is missing.

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?

Schema coverage is 100%, so baseline is 3, but the description adds conditional semantics the schema lacks: pass `runId` when the report concerns a `run`, omit it when the problem is a `get_library` coverage gap. It stops short of any guidance on how to phrase `report` itself or what the 4000-char limit implies.

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 action and object ('Record what was missing, wrong, or incomplete so Bowmark can build it') and immediately differentiates itself from siblings by naming `run`, `get_library`, and `support` with the exact role each plays. An agent can tell this apart from `support` (live chat escalation) without opening either schema.

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?

Gives an explicit trigger list: `run` errors or times out, returns `partial`, returns nothing from a responsive site, or returns untrustworthy data, plus the `get_library` miss case. It also states when NOT to retry and how to escalate to `support`, which is exactly the when/when-not/alternative structure the dimension asks for.

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.