Skip to main content
Glama
Heliyos MCP server

Heliyos MCP server

Official
by heliyos-ai

Get an object's fields

heliyos_objects_get
Read-onlyIdempotent

Retrieves an object's field keys, labels, types, and required status, with optional select options and relationship targets, to configure records and fields correctly.

Instructions

Returns one object's fields: each field key (what heliyos_records_create, _update and _list filters take), its label and type, and which are required. "detailed" adds the allowed values of select fields, hidden and AI-filled flags, and the target object of relationship fields. Pick the object with object_type (company, person, deal, or custom with schema_id from heliyos_objects_list). Each field's field_id feeds heliyos_fields_update and heliyos_fields_delete; heliyos_fields_create adds one. Returns structuredContent {object:{schema_id, name, fields:[{key, field_id, type, ...}]}}.

Input Schema

NameRequiredDescriptionDefault
schema_idNoObject schema id. Required when object_type is "custom"; the error lists the available ones.
object_typeYesWhich object: "company", "person", "deal", or "custom" (custom objects also need schema_id).
response_formatNo"concise" (default) returns each field's key, label and type; "detailed" returns select options and field flags too.concise

Output Schema

NameRequiredDescriptionDefault
objectYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.1

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already establish the safe read-only, idempotent profile, so the description's job is to add context — and it does: it explains that 'detailed' changes the payload to include select options, hidden/AI-filled flags and relationship targets. It also notes the structuredContent shape. Minor redundancy with the output schema keeps it from a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the return contract, then the object-selection rule, then downstream tool routing — a sensible order. It is dense rather than padded, though the run of sibling tool references (records_create/update/list, fields_create/update/delete) compresses a lot into one paragraph.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a three-parameter read tool with full schema coverage, annotations, and an output schema, the description covers selection rules, response modes, error fallback for custom schemas, and follow-up tools. Nothing an agent needs to invoke it correctly is missing.

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 all three parameters are already documented, giving a baseline of 3. The description reinforces the custom/schema_id dependency and clarifies that 'detailed' surfaces allowed select values and flags, but adds little syntax or constraint detail beyond the schema.

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?

Opens with a specific verb and resource: 'Returns one object's fields', then enumerates exactly what each field carries (key, label, type, required) and what 'detailed' adds. It is clearly distinguishable from heliyos_objects_list (which supplies schema_id) and from the field-mutation siblings it feeds.

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?

It states how to pick the object (object_type, with custom requiring schema_id from heliyos_objects_list) and routes the returned field_id to heliyos_fields_update/_delete and new fields to heliyos_fields_create. What's missing is an explicit disambiguation from heliyos_records_get / heliyos_records_list, which an agent might confuse with schema inspection versus record data.

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