Skip to main content
Glama
Sign In
dos2-gm-mcp

dos2-gm-mcp

by o-shabashov
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Search templates across campaigns

dos2_find_templates
Read-onlyIdempotent

Search saved Game Master templates across all campaigns or one, filter by name, StatName, skills, items, and kind, then return matching summaries with their campaign.

Instructions

Searches saved Game Master templates in every campaign on disk (or in one) and returns matching summaries with the campaign each one lives in. Larian's sample campaigns are included, so this works as a library of ready NPCs.

Read-only. Use it to find a template to copy: pass a hit to dos2_put_npc_template as base="Campaign:Name". To
list one campaign's templates without searching use dos2_templates.

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

Input Schema

NameRequiredDescriptionDefault
kindNoFilter by kind: "npc" or "item". Omit for both.
limitNoMaximum number of hits to return (default 30).
queryNoCase-insensitive substring matched against the template name, StatName, root template, skills and items. Empty matches everything.
campaignNoSearch only this campaign (name, folder, UUID or a part). Omit to search all campaigns.

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv0.1.1
    • addedInput schema / properties / campaign / description
      Added value: +"Search only this campaign (name, folder, UUID or a part). Omit to search all campaigns."
    • addedInput schema / properties / kind / description
      Added value: +"Filter by kind: \"npc\" or \"item\". Omit for both."
    • addedInput schema / properties / limit / description
      Added value: +"Maximum number of hits to return (default 30)."
    • addedInput schema / properties / query / description
      Added value: +"Case-insensitive substring matched against the template name, StatName, root template, skills and items. Empty matches everything."
  2. First observedv0.1.0

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so 'Read-only' is largely redundant. What the description does add beyond the structured fields is scope ('in every campaign on disk') and the non-obvious fact that Larian's sample campaigns are indexed, which changes what an agent can expect to find. It does not mention result ordering or cost of scanning all campaigns, which keeps it short of a 5.

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 purpose, then usage routing, then the alternative — a sensible order with no filler sentences. The standalone fragment 'Read-only.' and the trailing blank-line paragraph break are slightly choppy and duplicate the annotation, costing a point.

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, so return values need no explanation, and annotations cover the safety profile for this read operation. With fully documented parameters and a named alternative plus a downstream handoff example, an agent has everything needed to select and call it correctly.

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% and each of the four parameters already carries a description covering kind values, the limit default, query matching fields, and campaign matching forms. The description only reinforces the campaign scope ('or in one') without adding syntax or format detail, 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 ('Searches saved Game Master templates') plus the scope ('in every campaign on disk (or in one)') and the return shape ('matching summaries with the campaign each one lives in'). It also distinguishes itself from the sibling dos2_templates by naming it as the non-searching listing alternative.

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 explicit when-to-use ('Use it to find a template to copy'), the concrete downstream step ('pass a hit to dos2_put_npc_template as base="Campaign:Name"'), and the exclusion case ('To list one campaign's templates without searching use dos2_templates'). Nothing is left to inference.

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

Deploy Server

Other Tools