Skip to main content
Glama
Assetto Corsa Cinematic Director MCP

Assetto Corsa Cinematic Director MCP

list_camera_tools

Lists built-in and detected third-party Assetto Corsa camera tools and clarifies native control limits. Use it to inventory available camera options before planning cinematic shots.

Instructions

List built-in and detected third-party camera tools without claiming native control.

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

Input Schema

NameRequiredDescriptionDefault
game_dirNo
documents_dirNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.2

TDQS

C2.2/5.0
Behavior2/5

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

No annotations are supplied, so the description carries the full burden, and it discloses almost nothing. It hints at a limitation (no native control claim / detection of third-party tools) but never says what directories are scanned, whether results include undetected or unsupported tools, or how the two path parameters change behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

It is a single front-loaded sentence with no padding, which is good. But the trailing clause "without claiming native control" is ambiguously worded and consumes space that could have described the two path parameters or the discovery scope.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/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 format needn't be explained, but the tool has two undocumented path parameters with defaults and an undisclosed scan behavior. For a discovery tool whose results presumably depend on those paths, the description leaves too much for the agent to guess.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

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

Schema description coverage is 0%: game_dir and documents_dir have no descriptions, formats, or examples anywhere. The description does not mention either parameter or explain that it controls where detection scans, so an agent learns nothing about them beyond their names.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a verb ("List") and a resource ("built-in and detected third-party camera tools"), so the basic action is inferable. However, "camera tools" is never defined, and it does not distinguish this listing from siblings such as list_camera_presets or list_pp_filters, which an agent would need in order to pick the right list tool.

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

Usage Guidelines2/5

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

There is no statement of when to call this instead of the other list/validate siblings, no prerequisites, and no exclusions. The only hint is the phrase "without claiming native control," which implies a discovery-only role but never says when discovery is the right step.

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