SceneScout

Overview Schema Source Related Servers Discussions Admin

Preview problems as tickets

scout_ticket_preview

Read-only

Preview filing selected problems as GitHub or Jira tickets by checking which are already tracked, returning would-be and existing tickets plus a 10-minute preview ID without sending anything.

Instructions

Preview filing the problems the person chose as GitHub or Jira tickets. Reads the tracker to find which are already filed (by the marker scenescout export writes) and sends nothing. Returns each ticket that would be filed, the ones already filed, any over the limit of one filing, and a previewId that lasts 10 minutes. Show the person the list; to file it, call scout_ticket_file with the previewId. to: "github" with target the repository as owner/name, or "jira" with target the project key (the Jira site is JIRA_BASE_URL in the server's settings). The tracker's sign-in comes from the server's environment or the desktop extension's settings only (GH_TOKEN or GITHUB_TOKEN; JIRA_EMAIL and JIRA_API_TOKEN): never ask the person for a token and never pass one. Touches no browser.

Input Schema

Name	Required	Description
`to`	Yes	Where the team keeps its tickets
`ids`	Yes	The finding ids the person chose, as scout_cards shows them
`target`	Yes	GitHub: the repository as owner/name. Jira: the project key, such as "QA"

Output Schema

Name	Required	Description	Default
`to`	Yes
`cap`	Yes
`later`	Yes
`where`	Yes
`toFile`	Yes
`leftOut`	Yes
`createdAt`	Yes
`expiresAt`	Yes
`previewId`	Yes
`alreadyFiled`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed13 schema fields changedv3.31.0Oct 26, 2026
- removedInput schema / additionalProperties
```
Removed value: -false
```
- removedOutput schema / properties / alreadyFiled / items / properties / id / $ref
```
Removed value: -"#/properties/toFile/items/properties/id"
```
- addedOutput schema / properties / alreadyFiled / items / properties / id / type
```
Added value: +"string"
```
- removedOutput schema / properties / alreadyFiled / items / properties / severity / $ref
```
Removed value: -"#/properties/toFile/items/properties/severity"
```
- addedOutput schema / properties / alreadyFiled / items / properties / severity / enum
```
Added value: +[
+  "high",
+  "medium",
+  "low"
+]
```
- addedOutput schema / properties / alreadyFiled / items / properties / severity / type
```
Added value: +"string"
```
- removedOutput schema / properties / alreadyFiled / items / properties / title / $ref
```
Removed value: -"#/properties/toFile/items/properties/title"
```
- addedOutput schema / properties / alreadyFiled / items / properties / title / type
```
Added value: +"string"
```
- removedOutput schema / properties / later / items / $ref
```
Removed value: -"#/properties/toFile/items"
```
- addedOutput schema / properties / later / items / additionalProperties
```
Added value: +false
```
- addedOutput schema / properties / later / items / properties
```
Added value: +{
+  "id": {
+    "type": "string"
+  },
+  "severity": {
+    "enum": [
+      "high",
+      "medium",
+      "low"
+    ],
+    "type": "string"
+  },
+  "title": {
+    "type": "string"
+  }
+}
```
- addedOutput schema / properties / later / items / required
```
Added value: +[
+  "id",
+  "severity",
+  "title"
+]
```
- addedOutput schema / properties / later / items / type
```
Added value: +"object"
```
Addedv3.28.0Oct 18, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations declare readOnlyHint and openWorldHint, and the description goes well beyond them: it says the tracker is read to detect markers, that nothing is sent, that a previewId expires after 10 minutes, that over-limit items are surfaced, and that no browser is touched. Credential sourcing (GH_TOKEN/GITHUB_TOKEN, JIRA_EMAIL/JIRA_API_TOKEN from env or desktop settings) is disclosed too.

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?

Front-loaded with the preview/read-only guarantee and the file-this-later handoff before dipping into parameter and credential detail. Mostly tight, but the mid-sentence splice starting with 'to: "github" with target...' reads as a run-on fragment rather than a clean clause.

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?

An output schema exists, yet the description still summarizes what comes back (tickets that would be filed, ones already filed, over-limit, previewId) so the agent knows the shape of the decision surface without parsing the schema. For a read-only preview with three required params, nothing material 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 3 is the baseline, but the description adds real meaning: it ties `to` values to the shape of `target` (owner/name for GitHub, project key for Jira) and reveals where the Jira site comes from (JIRA_BASE_URL in server settings). `ids` is only loosely characterized ('the problems the person chose'), leaving the schema to carry the maxItems/format detail.

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?

Opens with a specific verb+resource: 'Preview filing the problems the person chose as GitHub or Jira tickets.' It is cleanly distinguished from the sibling scout_ticket_file, which is named as the follow-up step, so an agent cannot confuse the dry-run with the write.

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?

States exactly when to call it ('show the person the list') and the alternative path ('to file it, call scout_ticket_file with the previewId'). It also gives explicit negative guidance about credentials: never ask the person for a token and never pass one.

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