Skip to main content
Glama
Sign In

dotsy

by ai.dotsy
OverviewDiscussionsAdmin

get_report

Read-onlyIdempotent

Your dotsy bug reports. Omit id for the list; pass id for one ticket and its public replies.

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

Input Schema

NameRequiredDescriptionDefault
idNoOmit for your list; pass a ticket id for one report and its replies.
cursorNo
contextNoWhy you're calling this (activity log).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • removedInput schema / $schema
      Removed value: -"http://json-schema.org/draft-07/schema#"
    • changedInput schema / properties / context / description
      Previous value: -"Optional: one sentence on why you are calling this (shown in the site's activity log; no personal data)."New value: +"Why you're calling this (activity log)."
  2. Changed3 schema fields changed
    • changedInput schema / properties / context / description
      Previous value: -"One sentence: why you are calling this tool and what you are trying to accomplish. Stored on the site's activity log and visible to everyone on the site — never put secrets or personal data here."New value: +"Optional: one sentence on why you are calling this (shown in the site's activity log; no personal data)."
    • removedInput schema / properties / guestToken
      Removed value: -{
-  "description": "Guest token from start_site. Send it on every call until claim_site. Omit when this chat is already signed in to Dotsy.",
-  "minLength": 20,
-  "type": "string"
-}
    • removedInput schema / required
      Removed value: -[
-  "context"
-]
  3. Added

TDQS

A3.6/5.0
Behavior3/5

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

The annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered. The description does add one genuinely useful behavioral fact beyond that, namely that single-ticket retrieval includes public replies (implying non-public replies are excluded), but it says nothing about result volume, pagination, or ordering despite a cursor parameter existing.

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?

Two short sentences with no filler, and the list-vs-single distinction is front-loaded where an agent will see it first. Slightly cryptic phrasing ('dotsy') costs a bit of immediate comprehension.

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 small, read-only, no-output-schema tool this covers the essentials: scope, auth-owned data, and both return shapes. It does not explain the cursor/pagination contract, which is the one thing an agent could get wrong when the list is long.

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 67%: id and context are documented in the schema, and the description's id semantics largely restate the schema's own wording. The cursor parameter has no description in either the schema or the tool description, and the description does not compensate for that gap, so this sits at the baseline.

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 specific resource (your bug reports) and verb (get/list) and makes the dual-mode behavior explicit: omit id for a list, pass id for a single ticket with its public replies. It does not, however, distinguish this tool from nearby siblings such as support_inbox, report_bug, or reply_to_report, so the agent must infer the boundary.

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

Usage Guidelines4/5

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

It gives an explicit, actionable condition for the main usage decision: omit id for the list, pass id for one ticket. What is missing is any exclusion or pointer to alternatives (when to prefer report_bug or reply_to_report instead), so it is clear context without sibling routing.

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

All dotsy toolsInspect
Try in Browser
Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources