Skip to main content
Glama
Open2077

open77-devkit

by Open2077
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Hybrid

Game data catalogues

open77_data
Read-only

Look up Open77 game-data records by catalogue and optional query. Returns fields the server answers from Open77.data.*, with paging.

Instructions

Look up game-data names; animation inventories are discovery data, not playback allowlists. Arguments: catalogue (one of vehicles, weapons, items (clothing), npc-templates, props, vfx, sfx, animations, animsets) and an optional query. Query matches the record/path/name; returns the fields the server itself answers Open77.data.* from. Vehicle records a player may spawn end in _player (the others are quest/scene vehicles).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoRows per page, default 25
queryNoSubstring or words to match; omit for the catalogue summary
offsetNoSkip this many matches (paging)
catalogueYesvehicles | weapons | items | npc-templates | props | vfx | sfx | animations | animsets

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.1.1
    • addedInput schema / properties / limit / description
      Added value: +"Rows per page, default 25"
    • changedInput schema / properties / limit / maximum
      Previous value: -100New value: +200
    • addedInput schema / properties / offset
      Added value: +{
+  "description": "Skip this many matches (paging)",
+  "minimum": 0,
+  "type": "integer"
+}
  2. First observedv0.1.0

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, and the description does not contradict this. It adds valuable behavioral context beyond the annotation: it explains that the tool returns 'the fields the server itself answers Open77.data.* from,' clarifies that animation inventories are discovery data (not playback), and notes the '_player' suffix convention for spawnable vehicles. This enriches the agent's understanding of what the tool does and its constraints, though it does not cover all potential behaviors like pagination (handled in schema).

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?

The description is concise at roughly four sentences, front-loading the purpose ('Look up game-data names') and then adding necessary detail. It has no fluff or redundancy—the parenthetical list of catalogues is useful even though it duplicates the schema, and the vehicle suffix insight is valuable. It could be slightly tighter, but it earns its place.

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

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only catalogue lookup tool with 4 parameters and no output schema, the description covers the essential usage: purpose, catalogue enumeration, query behavior, return nature, and a naming nuance for vehicles. Pagination and limits are already in the schema, so the description doesn't need to repeat them. It is complete enough for an agent to call this tool correctly, though it does not explicitly state that the 'catalogue' parameter is required (the schema does).

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?

Since schema description coverage is 100%, the baseline is 3. The description adds meaning beyond the schema by explaining that 'query matches the record/path/name' (schema just says 'Substring or words to match'), and it gives the '_player' suffix convention for vehicles, which is not in the schema. It also lists the catalogue values in the description, reinforcing but not contradicting the schema's enum description.

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?

The description clearly states a specific verb+resource: 'Look up game-data names,' and enumerates the exact catalogues available (vehicles, weapons, items, etc.). It also distinguishes itself from playback by noting 'animation inventories are discovery data, not playback allowlists,' which clarifies its role. This is specific enough to separate it from sibling tools like open77_search without opening the schema.

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

Usage Guidelines3/5

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

The description implies usage (for looking up game-data names) and provides a useful caveat about animation inventories being discovery data, but it does not explicitly mention alternatives or when not to use this tool. No sibling tools are referenced for contrast, leaving the agent to infer that this is the tool for catalogue lookups without exclusion guidance.

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