Skip to main content
Glama

create_custom_field

Define a new custom field on a billing entity type (project, task, subtask, time report, or customer) for your organization. The organization is fixed by your context - never pass an organization id. type is one of String, Number, Date, DateTime, ListOfValues; ListOfValues requires at least one option. Marking a field mandatory blocks creating that entity type until a value is provided.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
typeYesField data type (required). One of: String, Number, Date, DateTime, ListOfValues.
titleYesHuman-readable label shown in the UI (required).
entityYesThe entity type this field is defined on (required). One of: billing_projects, billing_tasks, billing_sub_tasks, sub_tasks_time_reports, billing_customers.
field_idYesA unique, stable key for the field (required, max 50 chars), e.g. "po_number".
is_mandatoryNoWhether a value is required when creating/updating the entity. Defaults to false.
list_of_valuesNoOptions for a ListOfValues field (required for that type; at least one non-blank option).
idempotency_keyNoOptional caller-supplied key; retrying with the same key returns the original result instead of acting twice.

TDQS

A4.4/5.0
Behavior4/5

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

No annotations provided, but description discloses key behaviors: organization is fixed, ListOfValues requires options, mandatory blocks entity creation. Does not mention idempotency behavior or rate limits, but covers main effects.

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?

Three concise sentences front-load the purpose, then add essential details. No wasted words.

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?

With 7 parameters and no output schema, the description covers main aspects: entity, field_id, title, type, mandatory, list_of_values. Idempotency key is in schema but not description, but overall sufficient for a creation tool.

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%, so baseline 3. Description adds value by explaining context (fixed organization), clarifying ListOfValues requirement, and describing mandatory field impact.

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 creates a custom field on billing entity types, lists the entities and data types, and distinguishes from sibling tools like update_custom_field and delete_custom_field.

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?

Provides guidance on usage: do not pass organization id, ListOfValues requires options, mandatory blocks creation. Could explicitly mention alternative tools for updating/deleting, but context is clear.

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.

TDQS

B3/5.0
Disambiguation2/5

Multiple tools have overlapping purposes, e.g., create_time_report and log_time both create a single time entry with near-identical descriptions. There are also many similar getter/list tools that blur together, making it hard for an agent to select the right one.

Naming Consistency2/5

Most tool names use snake_case, but verbs are inconsistent: 'list' vs 'get' for similar operations, 'manage' combines create/update/delete, and 'use_favorite' is an outlier. This pattern reduces predictability.

Tool Count1/5

With 114 tools, the set is extremely large and far beyond a well-scoped server (typical 3-15). This overwhelms agents and suggests many tools could be consolidated or removed.

Completeness3/5

The tool surface covers a broad domain including customers, projects, tasks, time tracking, invoicing, and user management, but there are gaps like no list_users or direct user listing, and some operations seem redundant rather than filling missing functionality.

Resources