Skip to main content
Glama

query_kg_edges

Explore relationships in a knowledge graph by filtering edges based on entity names or relationship types. Retrieve connections between deals, investors, startups, and scoring data with detailed metadata.

Instructions

Traverse Knowledge Graph edges by entity name and/or relationship type. Returns edges with source/target node IDs, relations, scores, and metadata. Use this to explore deal relationships, investor-startup connections, and scoring edges. Gracefully returns empty results if the Knowledge Graph is not configured.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
entityNameNoFilter edges by entity name
relationshipTypeNoFilter edges by relationship type (e.g., "INVESTED_IN", "SCORED")
limitNoMax edges to return (default 100, max 500)

Implementation Reference

  • The MCP tool registration and handler implementation for 'query_kg_edges'. It defines the input schema using Zod and invokes the 'queryKgEdges' method on the client object.
        server.tool(
            'query_kg_edges',
            `Traverse Knowledge Graph edges by entity name and/or relationship type.
    Returns edges with source/target node IDs, relations, scores, and metadata.
    Use this to explore deal relationships, investor-startup connections, and scoring edges.
    Gracefully returns empty results if the Knowledge Graph is not configured.`,
            {
                entityName: z.string().optional().describe('Filter edges by entity name'),
                relationshipType: z.string().optional().describe('Filter edges by relationship type (e.g., "INVESTED_IN", "SCORED")'),
                limit: z.number().min(1).max(500).optional().describe('Max edges to return (default 100, max 500)'),
            },
            async ({ entityName, relationshipType, limit }, extra) => {
                const client = clientFactory(extra);
                const result = await client.queryKgEdges(entityName, relationshipType, limit);
                return {
                    content: [{
                        type: 'text' as const,
                        text: JSON.stringify(result, null, 2),
                    }],
                };
            }
        );
Behavior3/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 adds useful context by specifying what is returned (edges with IDs, relations, scores, metadata) and the graceful handling of an unconfigured Knowledge Graph. However, it lacks details on permissions, rate limits, or potential side effects, which are important for a query tool.

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 appropriately sized and front-loaded, with four concise sentences that each add value: stating the action, specifying returns, providing usage examples, and noting error handling. There is no wasted text, making it efficient and easy to parse.

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 complexity of a query tool with no annotations and no output schema, the description does well by explaining returns and error handling. However, it could improve by detailing output structure or pagination behavior, which would enhance completeness for an agent invoking this tool.

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?

The schema description coverage is 100%, so the schema already documents all parameters well. The description adds minimal value by implying filtering capabilities ('by entity name and/or relationship type') and example relationship types, but does not provide additional syntax or format details beyond what the schema offers, meeting the baseline for high coverage.

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 with specific verbs ('traverse', 'explore') and resources ('Knowledge Graph edges'), and distinguishes it from siblings by focusing on edge traversal rather than operations like creating workflows or getting knowledge rows. It explicitly mentions what it returns and its graceful handling of unconfigured states.

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?

The description provides clear context for when to use this tool ('to explore deal relationships, investor-startup connections, and scoring edges'), which helps differentiate it from siblings like 'get_knowledge_rows' or 'get_scoring_history'. However, it does not explicitly state when not to use it or name specific alternatives, keeping it from a score of 5.

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/Agentled/mcp-server'

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