Skip to main content
Glama

create_dictionary_override

Create or update a ServiceNow Dictionary Override on a child table to change inherited field behavior without modifying the parent table. Sets both values and override flags correctly.

Instructions

Create or update a ServiceNow Dictionary Override on a child table.

Dictionary overrides let you change how an inherited field behaves in a child table WITHOUT modifying the parent table's dictionary entry. This is the correct SN best practice for table extensions (e.g. incident extends task).

IMPORTANT: Each override requires BOTH a value AND its matching override_X=true flag. This tool sets them correctly — doing it manually often silently fails.

Supported overrides (specify any combination): mandatory — Make the field required in the child table (true/false) default_value — Set a different default value for the child table column_label — Rename the field label in the child table only read_only — Make the field read-only in the child table (true/false) display — Show or hide the field in the child table (true/false) calculation — Override a calculated field formula (script string) choice — Override the choice list (use create_choice to add child-table choices, then set this) dependent — Override the dependent field name

Examples: Make "business_service" mandatory on incident (but not on task): table="incident" field="business_service" overrides={mandatory: true}

Set a different default priority on change_request than task: table="change_request" field="priority" overrides={default_value: "3"}

Rename "caller_id" label to "Requested By" on sc_request: table="sc_request" field="caller_id" overrides={column_label: "Requested By"}

Hide a parent field on a specific child table: table="hr_case" field="parent" overrides={display: false}

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tableYesChild table name (e.g. "incident", "change_request", "hr_case")
fieldYesField (element) name inherited from the parent table (e.g. "priority", "caller_id")
overridesYesOne or more override properties to apply
dry_runNoPreview the payload without creating
Behavior5/5

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

With no annotations, the description fully informs about behavior: it performs a create/update, requires both value and override_X flag, and lists supported override properties with details. It also warns about silent failures if done manually. No contradictions.

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 well-structured: first a concise action statement, then purpose, important note, supported overrides list, and examples. Every sentence adds value, and the key info is front-loaded.

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?

Given the tool's complexity (4 params, nested overrides object) and no output schema, the description is complete. It explains the override mechanism, lists all supported fields, and provides examples for common use cases. It covers prerequisites and best practices.

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?

The input schema has 100% coverage, but the description adds significant value by explaining each override property with usage examples and clarifications (e.g., 'use create_choice to add child-table choices, then set this'). It also illustrates usage via code examples.

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's purpose: 'Create or update a ServiceNow Dictionary Override on a child table.' It explains the concept of dictionary overrides and how they differ from modifying parent entries. This distinguishes it from sibling tools like delete_dictionary_override and get_dictionary_overrides.

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 context on when to use this tool (for table extensions in ServiceNow) and notes that it is best practice. It implicitly guides against manual setup which often fails. However, it does not explicitly list when not to use it or specify alternatives beyond the sibling list.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/pinnintisagarSB/ServiceNow-Dev-MCP'

If you have feedback or need assistance with the MCP directory API, please join our Discord server