Skip to main content
Glama

Define object type

define_object

Create a new custom object TYPE (e.g. Partner, Product, Investor) to operate on via create_record / update_record / search_records (admin-only). Anti-sprawl: if a similar object exists this returns a suggestion to reuse it — pass confirm_new:true to create anyway. display_field names the data key holding a record's display name (default 'name'); the entity matcher and cards use it. Returns the created object definition.

When to use: When an admin wants to track a kind of thing the built-in objects don't cover — a genuinely new noun, not a relationship type (investor or partner are stickers on a company or person). Anti-sprawl checks for near-duplicates first.

Example: We manage real estate — add a Property object.

Input Schema

NameRequiredDescriptionDefault
iconNoA key from Capable's curated object-icon set (e.g. landmark, factory, handshake, flask); an unknown key is rejected with suggestions. Omit for the neutral default.
blurbNoOne short sentence saying what records of this object represent; shown in describe_schema and Settings.
labelYesSingular display name, e.g. Partner. Its slug (lowercase, underscores) becomes the object's stable key; a built-in's key is refused.
pluralNoPlural display name for lists and the menu. Defaults to the label + "s".
sharedNotrue lets any non-viewer edit every record of this object; false (the default) lets only the record's owner, admins and managers edit it.
confirm_newNoPass true to create even when a similar object exists; otherwise the anti-sprawl check returns the matches instead of creating.
display_fieldNoThe data key holding a record's display name — a lowercase field key such as "name" or "fund_name"; defaults to "name".

Output Schema

NameRequiredDescriptionDefault
objectNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • removedInput schema / $schema
      Removed value: -"https://json-schema.org/draft/2020-12/schema"
  2. Changed4 schema fields changed
    • removedOutput schema / $schema
      Removed value: -"https://json-schema.org/draft/2020-12/schema"
    • removedOutput schema / additionalProperties
      Removed value: -{}
    • removedOutput schema / properties / object / additionalProperties
      Removed value: -{}
    • removedOutput schema / properties / object / propertyNames
      Removed value: -{
      -  "type": "string"
      -}
  3. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the annotations (which only declare a non-read-only, non-destructive, non-idempotent write), the description discloses that the call is admin-only, that the anti-sprawl check can return matches INSTEAD of creating, and that display_field drives the entity matcher and cards. These are outcome-changing behaviors an agent could not infer from structured fields.

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 core action and the anti-sprawl behavior, then a when-to-use block and an example. Slightly penalized because anti-sprawl is stated twice (once inline, once in the when-to-use paragraph), which is redundant.

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?

An output schema exists, so return values need not be spelled out (the summary line 'Returns the created object definition' suffices). For a 7-parameter admin mutation, the description covers authorization, side-effect behavior, and the confirm escape hatch — everything needed to invoke it correctly.

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 already 100%, so the baseline is 3. The description goes slightly further by explaining downstream semantics — that display_field feeds the entity matcher and cards, and that confirm_new is the mechanism to override anti-sprawl — adding meaning beyond the schema's field-level text.

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?

States a specific verb and resource ('Create a new custom object TYPE') with concrete examples (Partner, Product, Investor) and explicitly ties it to how the type is then used (create_record / update_record / search_records). This cleanly separates it from siblings like update_object, define_field, and define_pipeline.

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?

Has a dedicated 'When to use' section stating the triggering condition (an admin tracking a kind of thing built-in objects don't cover), an exclusion (not a relationship type — investor/partner are stickers on a company or person), and the anti-sprawl escape hatch (confirm_new:true). Nothing is left to inference.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources