Skip to main content
Glama
rad-security

RAD Security

Official
by rad-security

query_knowledge_base_document

Query CSV documents in the RAD Security knowledge base using natural language questions to extract security insights from structured data.

Instructions

Query a CSV document from the knowledge base using natural language. IMPORTANT: This tool ONLY works with CSV documents. Use list_knowledge_base_documents with filters='file_type:csv' to find CSV document IDs (search_knowledge_base results also contain document IDs). Results are returned as a markdown table

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
document_idYesThe ID of the CSV document to query. Use list_knowledge_base_documents with filters='file_type:csv' to find CSV document IDs. Document IDs are also available in search_knowledge_base results. This will fail if the document is not a CSV file.
queryYesNatural language question to execute against the CSV document. The system will analyze the CSV structure and generate the appropriate query (e.g., 'Show me all rows where severity is critical', 'Count the number of vulnerabilities by type', 'Show me the owner of asset IKM99832').

Implementation Reference

  • The core handler function `structuredQueryDocument` that executes the tool logic by sending a POST request to the RAD Security API endpoint `/knowledge_base/documents/{documentId}/query` with the natural language query.
    export async function structuredQueryDocument(
      client: RadSecurityClient,
      documentId: string,
      query: string,
    ): Promise<any> {
      const tenantId = await client.getTenantId();
    
      const body = { query };
    
      return client.makeRequest(
        `/tenants/${tenantId}/accounts/${client.getAccountId()}/knowledge_base/documents/${documentId}/query`,
        {},
        {
          method: "POST",
          body: body,
        }
      );
    }
  • Zod schema defining the input parameters: `document_id` (string) and `query` (string) for the tool.
    export const StructuredQueryDocumentSchema = z.object({
      document_id: z.string().describe("The ID of the CSV document to query. Use list_knowledge_base_documents with filters='file_type:csv' to find CSV document IDs. Document IDs are also available in search_knowledge_base results. This will fail if the document is not a CSV file."),
      query: z.string().describe("Natural language question to execute against the CSV document. The system will analyze the CSV structure and generate the appropriate query (e.g., 'Show me all rows where severity is critical', 'Count the number of vulnerabilities by type', 'Show me the owner of asset IKM99832')."),
    });
  • src/index.ts:569-575 (registration)
    Tool registration in the listTools handler, defining the tool name, description, and input schema (converted from Zod).
      name: "query_knowledge_base_document",
      description:
        "Query a CSV document from the knowledge base using natural language. IMPORTANT: This tool ONLY works with CSV documents. Use list_knowledge_base_documents with filters='file_type:csv' to find CSV document IDs (search_knowledge_base results also contain document IDs). Results are returned as a markdown table",
      inputSchema: zodToJsonSchema(
        knowledgeBase.StructuredQueryDocumentSchema
      ),
    },
  • src/index.ts:1519-1533 (registration)
    Tool call handler in the CallToolRequest handler that parses arguments with the schema and invokes the structuredQueryDocument handler function.
    case "query_knowledge_base_document": {
      const args = knowledgeBase.StructuredQueryDocumentSchema.parse(
        request.params.arguments
      );
      const response = await knowledgeBase.structuredQueryDocument(
        client,
        args.document_id,
        args.query
      );
      return {
        content: [
          { type: "text", text: JSON.stringify(response, null, 2) },
        ],
      };
    }
Behavior4/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behaviors: the tool is query-only (implied by 'Query'), it has a strict input requirement (CSV documents only), it processes natural language queries, and it returns results as markdown tables. It doesn't mention error handling, rate limits, or authentication needs, but covers the core operational behavior well.

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 efficiently structured with three sentences that each serve a distinct purpose: stating the core function, specifying the CSV-only constraint with prerequisite guidance, and describing the output format. There's no wasted text, and important information is front-loaded with 'IMPORTANT' emphasis.

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?

Given the tool's moderate complexity (2 required parameters, no output schema, no annotations), the description provides good coverage. It explains what the tool does, when to use it, how to prepare inputs, and what format results will take. The main gap is lack of output schema documentation, but the description compensates by specifying 'Results are returned as a markdown table.'

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 100%, so the schema already fully documents both parameters. The description adds some context about document_id sourcing (list_knowledge_base_documents with CSV filter) and query examples, but doesn't provide significant additional semantic meaning beyond what's in the schema descriptions. This meets the baseline expectation when schema coverage is complete.

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: 'Query a CSV document from the knowledge base using natural language.' It specifies the exact resource (CSV document), the action (query with natural language), and distinguishes it from siblings by emphasizing it ONLY works with CSV documents, not other document types.

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 provides explicit guidance on when to use this tool: 'This tool ONLY works with CSV documents.' It also specifies prerequisites: 'Use list_knowledge_base_documents with filters='file_type:csv' to find CSV document IDs (search_knowledge_base results also contain document IDs).' This clearly tells the agent how to obtain the required document_id parameter.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/rad-security/mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server