Skip to main content
Glama

search_fivem_native

Read-onlyIdempotent

Search official GTA and Cfx native indexes by name or hash to filter client/server API sets and retrieve source links for verifying native usage.

Instructions

Search the official GTA and Cfx native indexes by name/hash, with API-set filtering and source links. Network access only to two fixed official index URLs.

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": {
      "query": "<query>"
    },
    "name": "search_fivem_native"
  }
}

Input Schema

NameRequiredDescriptionDefault
sideNoany
limitNo
queryYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description earns credit for adding a concrete network boundary ('only to two fixed official index URLs'), which meaningfully narrows the broad openWorldHint, plus mentions API-set filtering and source links. It stops short of describing failure behavior when the network is unavailable.

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

Conciseness5/5

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

Two sentences, zero filler, with the core action and resource stated first and the network constraint as a follow-on caveat.

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

Completeness3/5

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

With no output schema, the description should say what a result looks like; 'source links' is the only hint at return content. For a simple read-only search this is close to adequate, but the meaning of `side` and the shape of results remain unstated.

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 description coverage is 0%, so the description has to carry parameter meaning and only partly does: 'by name/hash' usefully clarifies the `query` field beyond a bare 2-100 char string, and 'API-set filtering' hints at `side`. The `limit` parameter and the exact client/server/any semantics of `side` are left entirely to the schema, and 'API-set filtering' is too vague to be reliable.

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 gives a specific verb (Search) plus a precisely-scoped resource (the official GTA and Cfx native indexes) and names the lookup keys (name/hash). That is plainly a different resource class from every sibling (skill/topic lookups, resource inspection, fxmanifest validation), so an agent can route to it without ambiguity.

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 phrasing 'by name/hash' implies what kinds of queries are appropriate, which is light usage guidance. However, it never states when to prefer this over reviewing FiveM source code or inspecting a resource, nor any exclusions or prerequisites.

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