mcp-server-worldquantbrain

Overview Schema Source Related Servers Discussions Admin

List data fields

list_datafields

Read-onlyIdempotent

Find data fields usable in WorldQuant BRAIN expressions by type, delay, region, universe, dataset, or search; narrow results with dataset_id or search to avoid API truncation.

Instructions

Find the data fields usable in expressions.

BRAIN stops paging at 10,000 rows, so when truncated_by_api is true narrow with dataset_id or
search.

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

Input Schema

Name	Required	Description
`type`	No	MATRIX, VECTOR, GROUP or UNIVERSE.
`delay`	No	Data delay, 0 or 1.
`limit`	No
`order`	No	e.g. -coverage or -alphaCount.
`offset`	No
`region`	No	Market region, e.g. USA. Empty uses the default.
`search`	No
`category`	No
`universe`	No	Universe, e.g. TOP3000. Empty uses the default.
`dataset_id`	No	Restrict to one dataset.
`instrument_type`	No	EQUITY unless configured otherwise.

Output Schema

Name	Required	Description	Default
`count`	No
`items`	No
`next_offset`	No
`truncated_by_api`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 11, 2026

TDQS

A3.6/5.0

Behavior4/5

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

Annotations already declare this a read-only, idempotent, open-world read, so the safety profile is covered. The description adds non-obvious backend behavior beyond the annotations: BRAIN stops paging at 10,000 rows and surfaces a truncated_by_api signal. That is exactly the kind of platform quirk an agent cannot infer from structured fields.

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?

Two sentences, zero preamble, with the core purpose front-loaded and the caveat immediately after. The reference to truncated_by_api is slightly cryptic in isolation, but it is short and every sentence carries information.

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?

An output schema exists, so return values need no explanation, and the pagination caveat covers the main failure mode. But with 11 optional parameters and only 64% schema coverage, the description does not help an agent choose values for the filter/order dimensions that determine result set size and relevance.

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 64%, so several parameters (limit, offset, search, category, type) are undocumented in either place. The description adds meaning only for dataset_id and search (as narrowing filters) and implicitly ties offset to the 10,000 cap; it says nothing about order, delay, region, or instrument_type semantics. Baseline 3 is appropriate given partial schema coverage plus modest added context.

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?

"Find the data fields usable in expressions" states a specific verb (find/list) and resource (data fields) with a scope qualifier (usable in expressions) that separates it from get_datafield and list_datasets. It stops short of naming a sibling explicitly, but the purpose is unambiguous.

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 second sentence gives concrete operational guidance for the truncation case (narrow with dataset_id or search when truncated_by_api is true), which is genuinely useful. However, there is no guidance on when to use this versus get_datafield for a single field, nor on how the ordering/filtering parameters should be chosen to avoid hitting the 10,000-row ceiling in the first place.

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