Skip to main content
Glama
Sign In
headlo-mcp

headlo-mcp

Official
by headlohq
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

get_record

Retrieve a complete record by its ID and collection ID, returning all field values. Use this to access specific data directly without scanning entire collections.

Instructions

Get a single record by ID with all field values

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "collection_id": "<collection_id>",
      "record_id": "<record_id>"
    },
    "name": "get_record"
  }
}

Input Schema

NameRequiredDescriptionDefault
record_idYes
workspace_idNoWorkspace ID — omit to use the first workspace from context
collection_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.2

TDQS

A3.7/5.0
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. 'Get' implies a read-only operation and 'all field values' suggests the return content, but it omits any details about auth requirements, error handling, workspace_id resolution, or access restrictions.

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 a single, front-loaded sentence with no filler. It efficiently communicates the tool's core function without redundancy.

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?

The tool is simple with few parameters and no output schema. The description is mostly sufficient, clarifying purpose and return content. A minor gap is not mentioning that collection_id is required, though the schema does indicate this.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 33% (only workspace_id has a description). The description adds some meaning for record_id ('by ID') but doesn't elaborate on collection_id, which is a required parameter. This leaves a significant portion of the parameters contextually unexplained.

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?

Description uses specific verb 'Get' and clearly identifies the resource: 'a single record by ID' with scope 'all field values'. This distinguishes it from sibling tools like list_records and other record operations, making its purpose unambiguous.

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

Usage Guidelines3/5

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

Usage is implied by the description and name: use when you need a single record by ID. However, it doesn't explicitly state when to use this tool over list_records or other alternatives, nor does it provide any exclusions or prerequisites.

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

Deploy Server

Other Tools