quant-rag

Overview Schema Source Related Servers Discussions Admin

search_graph

Find passages that mention a named entity or fragment in the research corpus, using exact nominal matching to complement semantic search. Filter by entity type or relation for targeted exploration.

Instructions

Cherche dans le graphe d'entités : les passages qui MENTIONNENT une entité dont le nom contient query.

Complémentaire de search_documents (sémantique) : ici la correspondance est nominale et exacte — « Gatheral » retourne les passages où Gatheral est cité, « SVI » ceux où SVI apparaît, même quand la question sémantique ne les ferait pas remonter. Les entités ont été extraites par GLiNER2 sur chaque passage (personnes, organisations, instruments, concepts de marché, mesures, méthodes, jeux de données). Même format de sortie que search_documents : source citable, pages, chunk_id (pour get_passage), plus les entités reconnues dans le passage. Croiser avec search_documents : le graphe ne connaît que les noms, pas le sens.

Args: query: nom d'entité ou fragment (« Gatheral », « rough volatility », « SVI », « S&P 500 »). Casse et accents ignorés ; « Lopez de Prado » trouve « López de Prado ». entity_type: restreindre à un type : person, organization, financial_instrument, market_concept, measure, method, dataset. relation: ne garder que les passages où l'entité est tête ou queue d'une relation de ce type : measures, predicts, causes, depends_on, correlates_with, applies_to, uses_method, compares_with, is_a, part_of. top_k: nombre de passages (défaut 10, au plus 2 par document).

Input Schema

TableJSON Schema

Name	Required	Description	Default
`query`	Yes
`top_k`	No
`relation`	No
`entity_type`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.4.0Sep 26, 2026

TDQS

A4.9/5.0

Behavior5/5

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

With no annotations provided, the description carries the full behavioral burden. It discloses key behaviors: exact nominal matching ('correspondance est nominale et exacte'), case and accent insensitivity ('Casse et accents ignorés'), the entity extraction method (GLiNER2), the output format similarity to search_documents, and the constraint 'au plus 2 par document' for top_k. This goes well beyond the structured schema and sets correct expectations for an agent.

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 longer than the minimum, but every sentence earns its place: it covers purpose, differentiation, output format, and parameter semantics. The structure is logical, starting with the core function, then the sibling contrast, then parameter details. It is slightly verbose but not bloated, earning a 4 rather than a 5 for prose efficiency.

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

Completeness5/5

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

Given the output schema exists (as indicated by 'Has output schema: true'), the description need not detail return values. It still mentions the output format ('Même format de sortie que search_documents... plus les entités reconnues'). It covers all parameters, defaults, and usage context. Nothing essential is missing for an agent to invoke the tool correctly.

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

Parameters5/5

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

Schema description coverage is 0%, so the description must compensate, and it does thoroughly. Each parameter is explained: query with examples and matching behavior, entity_type with the full list of allowed values, relation with all possible relation types, and top_k with default and per-document limit. This gives the agent everything needed to construct correct arguments.

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 the tool's purpose: 'Cherche dans le graphe d'entités : les passages qui MENTIONNENT une entité dont le nom contient query.' It specifies the action (search), the resource (entity graph), and the exact operation (find passages mentioning an entity name containing the query). It also explicitly contrasts with search_documents, making it easy for an agent to choose the right tool.

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

Usage Guidelines5/5

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

The description gives explicit usage guidance: 'Complémentaire de search_documents (sémantique) : ici la correspondance est nominale et exacte' and later 'Croiser avec search_documents : le graphe ne connaît que les noms, pas le sens.' This clearly tells the agent when to use this tool (exact name matching) versus when to use the semantic sibling, and even suggests cross-referencing both tools.

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

Deploy Server