swsd-mcp

swsd_get_solution

Read-onlyIdempotent

Fetch a SWSD solution by internal ID or human-facing number, returning full description, custom fields, comment count, and attachment metadata. Search by topic first to find the ID.

Instructions

Fetch one SWSD solution. Accepts an internal id (>=7 digits) or human-facing number (<=6 digits). Returns the full solution as returned by SWSD (passthrough), including both description (HTML) and description_no_html (plain text) fields, custom_fields_values, comments count, and attachment metadata. Use swsd_search_solutions first if you only have a topic — IDs are not guessable. Pass detail_level: "long" to include attachments, audits, and tags in one call.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "id": "<id>"
    },
    "name": "swsd_get_solution"
  }
}

Input Schema

Name	Required	Description	Default
`id`	Yes	SWSD solution reference. Accepts an internal id (>=7 digits) or human-facing number (<=6 digits). The handler auto-detects via digit count.
`detail_level`	No	Use "long" to include attachments, audits, tags, and full statistics in one call. Default "short" is faster.	short

Output Schema

Name	Required	Description	Default
`solution`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv3.3.0Nov 5, 2026

changedInput schema / properties / id / description

Previous value: -"SWSD solution reference. Accepts either the internal id (>=7 digits) or the human-facing number (<=4 digits). The handler auto-detects via digit count."New value: +"SWSD solution reference. Accepts an internal id (>=7 digits) or human-facing number (<=6 digits). The handler auto-detects via digit count."

Changed2 schema fields changedv3.0.0Oct 4, 2026

changedInput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

changedOutput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

First observedv2.1.0May 28, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is free; the description adds real behavior beyond that by disclosing the payload is a passthrough containing both HTML and plain-text descriptions, custom_fields_values, comment counts, and attachment metadata. It also reveals that detail_level changes what is fetched (attachments, audits, tags) and that this avoids extra calls. The only shortfall is that return-value detail is partly redundant given an output schema exists.

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?

Content is front-loaded: what it fetches, then ID format, then return shape, then the alternative-routing advice. Every sentence is functional, though the ID digit-count rule and the detail_level explanation duplicate schema text and could be trimmed.

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?

For a two-parameter read tool with full annotation coverage and an output schema, an agent has everything needed: target resource, identifier disambiguation, escalation path to search, and the cost/benefit tradeoff of detail_level. Nothing required 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.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so both parameters are already documented, including the 7-digit vs 6-digit auto-detection rule and the enum/default for detail_level. The description restates both rules rather than adding syntax, formats, or edge cases the schema lacks, so the baseline 3 applies.

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 verb and resource ("Fetch one SWSD solution") and immediately distinguishes the scope from the sibling swsd_search_solutions by pointing at it for topic-based lookup. An agent can pick between the two 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?

Explicitly routes the agent: "Use swsd_search_solutions first if you only have a topic — IDs are not guessable," naming the alternative and the condition that selects it. It also gives a conditional call-shape recommendation ("Pass detail_level: \"long\" to include attachments, audits, and tags in one call"), so both when-to-use and how-to-batch are covered.

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

Deploy Server