QSIG Intelligence

list_geo_themes

Free. Theme keys, labels, linked assets, coverage (qualifying markets, whale USD held, sufficient flag), method version and field notes for get_geo_themes. Use it to decide whether a paid call is worth making.

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_geo_themes"
  }
}

Input Schema

Name	Required	Description	Default
No arguments

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

AddedSep 29, 2026

TDQS

A4/5.0

Behavior4/5

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

No annotations are provided, so the description carries the burden. It discloses pricing (Free), the return payload shape (keys, labels, assets, coverage, method version, field notes), and the preview role. Doesn't state rate limits or pagination, but the free-vs-paid distinction and payload disclosure are meaningful behavioral context.

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?

Three short sentences, front-loaded with 'Free.' and immediately clarifying the payload and purpose. Slightly telegraphic in listing fields, but no waste.

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?

With an output schema present, the description doesn't need to explain return values in detail, and it doesn't over-explain. It adequately covers the preview role and the free-tier positioning, though a nod to sibling tools (get_georisk, get_method, get_track_record) would help disambiguation.

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?

Zero parameters, so baseline is 4. The description appropriately focuses on what the call returns rather than parameter details, which is the right allocation of effort for a no-arg tool.

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

Purpose4/5

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

States it returns theme keys, labels, linked assets, coverage details, method version and field notes for get_geo_themes — a clear verb+resource inventory. Distinguishes from get_geo_themes by framing itself as the preview/free tier, though it doesn't name other siblings.

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

Usage Guidelines4/5

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

Explicitly says 'Use it to decide whether a paid call is worth making,' which ties usage to the paid sibling get_geo_themes. Clear context, but no explicit when-not-to-use or routing to get_georisk/get_method/get_track_record alternatives.

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

All QSIG Intelligence tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?