Skip to main content
Glama
subbuyalla

WeTrack Enterprise MCP Server

by subbuyalla

wetrack_create_metadata_field

Create custom metadata fields for tickets, projects, or sprints. Specify field type, options, and requirements to capture workflow-specific data.

Instructions

Create a new custom metadata field definition.

Args: resource_type: What the field belongs to — 'TICKET', 'PROJECT', or 'SPRINT'. label: Field label e.g. 'Cost Center'. field_type: Field input type — 'TEXT', 'NUMBER', 'DATE', 'BOOLEAN', 'SELECT', or 'MULTI_SELECT'. ticket_type: Required when resource_type is 'TICKET' — 'EPIC', 'STORY', 'TASK', 'BUG'. helper_text: Optional placeholder/helper text shown below the field. is_required: Whether this field is mandatory (default: False). options: Required for SELECT/MULTI_SELECT fields — list of option objects: [{"label": "Engineering", "value": "eng"}, ...]

Example: resource_type="TICKET", ticket_type="BUG", label="Environment", field_type="SELECT", options=[{"label": "Production", "value": "prod"}, {"label": "Staging", "value": "staging"}]

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
labelYes
optionsNo
field_typeYes
helper_textNo
is_requiredNo
ticket_typeNo
resource_typeYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4.4/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 behavioral burden. It states that this creates a new metadata field definition and documents defaults and conditional requirements, but it does not disclose side effects such as duplicate-label handling, whether the field becomes active immediately, or permission requirements.

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 front-loaded with a one-sentence purpose, then uses a compact Args list and a concrete example. Each sentence adds necessary information, and the structure makes conditional parameters easy to parse.

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 7-parameter create tool with conditional dependencies, the description covers every parameter, requiredness rule, and the options-object format. Since an output schema exists, not describing the return value is acceptable.

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

Parameters5/5

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

Schema description coverage is 0%, and the description fully compensates: it lists allowed values for resource_type, field_type, and ticket_type; explains label and helper_text; documents the is_required default; and specifies the exact options object format with an example.

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 first sentence, 'Create a new custom metadata field definition,' uses a specific verb and resource and clearly distinguishes this tool from sibling metadata tools like wetrack_update_metadata_field, wetrack_delete_metadata_field, and wetrack_get_metadata_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?

The description provides clear conditional guidance: ticket_type is required when resource_type is 'TICKET', and options are required for 'SELECT'/'MULTI_SELECT' fields. It does not explicitly name sibling alternatives, but the conditional parameter usage is strong enough for an agent to apply the tool correctly.

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