Skip to main content
Glama

get_entity

Retrieve canonical entity by UUID, with optional inclusion of linked records such as source_records or links.

Instructions

Fetch an AnchorID (canonical entity) by UUID. Optionally include linked source records via the include parameter (links, source_records, or both).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
entity_idYesUUID of the AnchorID to retrieve
includeNoComma-separated relations to include: "links", "source_records", or both

Implementation Reference

  • The async handler function that executes the get_entity tool logic. It takes entity_id and optional include parameters, makes a GET request to /entities/{entity_id} via ApiClient, and returns the JSON response or an error.
      async ({ entity_id, include }) => {
        try {
          const params: Record<string, string | undefined> = { include };
          const data = await api.get(`/entities/${entity_id}`, params);
          return jsonContent(data);
        } catch (e) {
          return errorContent(e);
        }
      },
    );
  • Zod schema defining the input parameters for get_entity: entity_id (required UUID string) and include (optional string for comma-separated relations like 'links', 'source_records').
    {
      entity_id: z.string().describe("UUID of the AnchorID to retrieve"),
      include: z
        .string()
        .optional()
        .describe(
          'Comma-separated relations to include: "links", "source_records", or both',
        ),
    },
  • src/tools.ts:214-237 (registration)
    The get_entity tool is registered via server.tool() with the name 'get_entity', inside the registerTools() function which is exported from src/tools.ts and called in src/index.ts.
    // ─── 5. get_entity ───────────────────────────────────────────────
    server.tool(
      "get_entity",
      "Fetch an AnchorID (canonical entity) by UUID. Optionally include linked " +
        "source records via the include parameter (links, source_records, or both).",
      {
        entity_id: z.string().describe("UUID of the AnchorID to retrieve"),
        include: z
          .string()
          .optional()
          .describe(
            'Comma-separated relations to include: "links", "source_records", or both',
          ),
      },
      async ({ entity_id, include }) => {
        try {
          const params: Record<string, string | undefined> = { include };
          const data = await api.get(`/entities/${entity_id}`, params);
          return jsonContent(data);
        } catch (e) {
          return errorContent(e);
        }
      },
    );
Behavior3/5

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

With no annotations, the description carries the full burden. It implies a read operation (fetch) and explains the optional inclusion of linked records, but does not disclose any behavioral traits such as permissions, side effects, or response details.

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 concise sentences with no wasted words. The purpose is front-loaded, and the optional behavior is immediately specified.

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?

While the description covers the basic functionality, it lacks details about the return format (e.g., structure of the fetched entity) and does not reference output schema. For a simple fetch, it is adequate but not thorough.

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?

Schema coverage is 100%, but the description adds value by clarifying the valid values for the 'include' parameter ('links', 'source_records', or both'), going beyond the schema's generic 'Comma-separated relations'.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Fetch') and the resource ('AnchorID by UUID'), with an optional parameter to include linked records. While it doesn't explicitly differentiate from siblings like 'get_entity_export', the purpose is unambiguous.

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?

No usage guidelines are provided. The description does not indicate when to use this tool versus alternatives, nor does it mention any prerequisites or exclusions.

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/nolenation04/anchord-mcp'

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