Skip to main content
Glama

query_concept

Look up a concept to find all variants, related concepts, naming conventions, function signatures, and file locations. Resolves questions like 'what is X', 'what does X mean', or 'where is X used'.

Instructions

Semantic concept lookup — returns all variants (including abbreviations like trf for transform), related concepts, naming conventions, function signatures, and file locations in one call. Richer than grep: querying 'transform' also finds 'trf', 'spatial_transform', 'apply_transform', and related concepts like 'displacement'. Use when asked 'what is X', 'what does X mean', or 'where is X used'.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
termYesThe concept term to look up (e.g. 'transform')
max_relatedNoMax related concepts to return (default: 10)
max_occurrencesNoMax occurrence locations to return (default: 5)
max_variantsNoMax variant identifiers to return (default: 20)
max_signaturesNoMax function signatures to return (default: 5)

Implementation Reference

  • Input schema for query_concept tool: defines parameters (term, max_related, max_occurrences, max_variants, max_signatures) with TypeBox validation.
    {
      mcpName: "query_concept",
      label: "Query Concept",
      description:
        "Semantic concept lookup — returns variants (including abbreviations), " +
        "related concepts, naming conventions, function signatures, and file locations.",
      promptSnippet:
        "ontomics_query_concept: semantic concept lookup with variants and relationships",
      parameters: Type.Object({
        term: Type.String({ description: "Concept term to look up" }),
        max_related: Type.Optional(
          Type.Integer({ description: "Max related concepts (default: 10)" }),
        ),
        max_occurrences: Type.Optional(
          Type.Integer({
            description: "Max occurrence locations (default: 5)",
          }),
        ),
        max_variants: Type.Optional(
          Type.Integer({
            description: "Max variant identifiers (default: 20)",
          }),
        ),
        max_signatures: Type.Optional(
          Type.Integer({
            description: "Max function signatures (default: 5)",
          }),
        ),
      }),
    },
  • Registration loop that registers all tools including query_concept via pi.registerTool(). The actual execute handler delegates to the MCP client calling the ontomics binary.
    for (const def of toolDefs()) {
      pi.registerTool({
        name: `ontomics_${def.mcpName}`,
        label: def.label,
        description: def.description,
        promptSnippet: def.promptSnippet,
        promptGuidelines: [
          "Use ontomics tools BEFORE grep/glob for semantic codebase questions.",
        ],
        parameters: def.parameters,
        async execute(_toolCallId, params, _signal, onUpdate, _ctx) {
          onUpdate?.({
            content: [{ type: "text", text: `Querying ontomics: ${def.mcpName}...` }],
          });
          try {
            const mcp = await getClient();
            const text = await mcp.callTool(def.mcpName, cleanArgs(params));
            return { content: [{ type: "text", text }] };
          } catch (err) {
            throw new Error(
              `ontomics ${def.mcpName} failed: ${err instanceof Error ? err.message : String(err)}`,
            );
          }
        },
      });
    }
  • Execute handler for query_concept: delegates to ontomics MCP server via McpClient.callTool(), passing cleaned parameters.
    async execute(_toolCallId, params, _signal, onUpdate, _ctx) {
      onUpdate?.({
        content: [{ type: "text", text: `Querying ontomics: ${def.mcpName}...` }],
      });
      try {
        const mcp = await getClient();
        const text = await mcp.callTool(def.mcpName, cleanArgs(params));
        return { content: [{ type: "text", text }] };
      } catch (err) {
        throw new Error(
          `ontomics ${def.mcpName} failed: ${err instanceof Error ? err.message : String(err)}`,
        );
      }
    },
  • McpClient.callTool() method that sends JSON-RPC request to the ontomics binary and extracts text response.
    async callTool(
      name: string,
      args: Record<string, unknown>,
    ): Promise<string> {
      const result = (await this.request("tools/call", {
        name,
        arguments: args,
      })) as { content?: Array<{ text?: string }> };
      const text = result.content?.[0]?.text ?? JSON.stringify(result);
      return text;
    }
  • McpClient.start() static factory that spawns the ontomics binary and initializes the MCP connection.
    static async start(binaryPath: string, cwd: string): Promise<McpClient> {
      const proc = spawn(binaryPath, ["serve"], {
        cwd,
        stdio: ["pipe", "pipe", "pipe"],
      });
      const client = new McpClient(proc);
      await client.request("initialize", {
        protocolVersion: "2024-11-05",
        capabilities: {},
        clientInfo: { name: "pi-ontomics", version: "1.0.0" },
      });
      client.notify("notifications/initialized", {});
      return client;
    }
Behavior4/5

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

While no annotations are provided, the description discloses that the tool returns multiple types of information in one call and gives a detailed example of query expansion. It does not explicitly state read-only or side-effect-free, but the name and context imply a query operation. Lacks some nuance like whether results are cached or ordered, but sufficient for most use cases.

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?

Two sentences plus a usage tip, all front-loaded with the core purpose. No filler, every word earns its place.

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 has 5 optional parameters and no output schema, the description covers the return types (variants, related concepts, etc.) reasonably well. It differentiates from grep but not from sibling tools like concept_map or locate_concept, which may overlap. Still, it's sufficiently complete for a query 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?

Schema coverage is 100%, so the schema already documents all parameters. The description adds no additional parameter-level meaning beyond the schema, e.g., no format constraints or examples. Baseline 3 is appropriate.

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 does a 'semantic concept lookup' returning variants, related concepts, naming conventions, function signatures, and file locations. It distinguishes from grep with a concrete example (querying 'transform' finds 'trf', etc.), making the purpose specific and actionable.

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?

Explicitly says when to use: 'when asked what is X, what does X mean, or where is X used'. Also contrasts with grep as an alternative, providing clear usage context without needing negative examples.

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/EtienneChollet/ontomics'

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