Skip to main content
Glama
angrysky56
by angrysky56

query_knowledge

Use natural language to search a knowledge graph and retrieve facts, insights, and reasoning trails for informed answers.

Instructions

Query the knowledge graph for facts and insights using natural language.

This tool provides the conversational interface to the knowledge base, prioritizing synthesized insights over raw facts.

Args: query: Natural language query include_insights: Whether to include AI-generated insights max_results: Maximum number of results to return

Returns: Query results with facts, insights, and reasoning trails

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
queryYes
max_resultsNo
include_insightsNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.5/5.0
Behavior2/5

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

Since no annotations are provided, the description carries the full burden of disclosing behavior. It mentions returning results but does not state whether the operation is read-only or has any side effects, nor does it describe limitations or error behavior.

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?

The description is concise and well-structured, beginning with a clear purpose statement, followed by a list of arguments and return values. It avoids redundancy and presents information in a logical order.

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?

The description covers the essential purpose and parameters, but lacks details on usage context, output schema specifics, and edge cases. Given the absence of annotations, some safety and behavior information is missing, leaving the description only partially complete.

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?

The input schema has no descriptions for its parameters, so the description's Args section serves as the sole explanation. It provides brief but meaningful explanations for query, include_insights, and max_results, adding value beyond the bare schema fields.

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 'Query the knowledge graph for facts and insights using natural language' and further specifies it provides the conversational interface to the knowledge base. This concise purpose statement clearly distinguishes the tool from its siblings.

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

Usage Guidelines2/5

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

The description does not explicitly state when to use this tool over alternatives like wiki_search or synapse_recall. It only hints at a focus on synthesized insights, but lacks clear guidance on appropriate use cases or exclusions.

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