ServiceNow MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.6.1
Disambiguation3/5
There is noticeable overlap between generic record tools (list_records, create_record, get_record) and CI-specific tools (list_ci, create_ci, get_ci), which could cause misselection. However, descriptions clearly distinguish CI tools by focusing on CMDB configuration items and their specific features like class filtering and relationships, so an agent can disambiguate with careful reading.
Naming Consistency4/5
Most tools follow a consistent verb_noun pattern (e.g., create_ci, update_record, list_update_sets). Minor deviations include list_ci using singular while other list tools use plural, and compound nouns like get_ci_relationships and set_current_update_set. Overall, the pattern is predictable and readable.
Tool Count4/5
With 19 tools, the count is slightly above the typical 3-15 range, but the server covers a broad scope including generic table operations, CI management, update set management, and system utilities. Each tool serves a distinct function, making the count reasonable for the intended purpose.
Completeness3/5
Generic table operations are fully covered with CRUD, list, aggregate, and schema retrieval. However, the CI sub-domain lacks delete_ci and relationship mutation, while update set management lacks update and delete operations. These gaps represent notable missing lifecycle operations for those specific areas.
Average 3.5/5 across 19 of 19 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- 3 of 3 community issues answered or closed in the last 6 months
- 17 commits in the last 12 weeks
- Last stable release on August 13, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the action without mentioning the required 'name' field, default class_name, validation behavior, or response format, leaving significant uncertainty for a create operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief, which is concise, but it under-delivers by merely expanding the acronym 'Ci' to 'configuration item.' It is not a tautology, yet it lacks the richer context that a truly helpful concise description would provide.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a nested data object and an output schema, but the description only states the high-level purpose. It does not cover essential context such as the mandatory name attribute, default class_value, return values, or how it differs from other create tools, making it incomplete for effective use.
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?
Both parameters have descriptions in the schema (data requires 'name', class_name has a default), giving 100% schema coverage. The description adds no additional parameter semantics, so it meets the baseline of 3 without going beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description provides a specific verb ('Create') and resource ('CMDB configuration item'), which clearly indicates the tool's function and distinguishes it from generic record creation. However, it does not explicitly reference sibling alternatives, so it is not a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives such as create_record or create_update_set. It lacks context, exclusions, or prerequisites, leaving the agent without direction on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. 'Update a CMDB configuration item' only implies a write operation without disclosing behaviors such as partial update semantics, required permissions, error handling, or whether it can create records. It adds minimal behavioral insight beyond the schema.
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 a single, clear sentence with no wasted words. It is appropriately concise and front-loaded, doing exactly what is needed to identify the tool's basic purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema and 3 parameters, but the description does not explain return values or provide usage context. Without annotations, it omits critical guidance on when to use this over update_record or what constitutes a valid update request. The minimalism leaves significant gaps for an agent.
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 the baseline is 3. The description does not add any parameter-specific meaning beyond the schema; it only names the resource. The schema already documents sys_id, data, and class_name, so no compensation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update a CMDB configuration item' clearly states the action (update) and the resource (CMDB configuration item). It distinguishes from generic tools like update_record by specifying the CMDB CI domain, though it doesn't explicitly name sibling alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like update_record or create_ci. The description lacks context about appropriate use cases, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavior itself, but it only says 'Query', which implies a read-only operation. It does not mention return format, pagination behavior, authentication requirements, or any constraints beyond those in the schema, leaving the agent to guess about important runtime characteristics.
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 a single, straight-to-the-point sentence with no redundant words. It earns its place by clearly stating the tool's purpose without fluff, matching the front-loaded style of high-performing examples.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and benefits from an output schema and well-documented parameters, making the minimal description somewhat adequate. However, it lacks context about what system properties are or when they are typically queried, leaving a slight gap for the agent in understanding the broader use case.
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?
The input schema describes both parameters (limit and query) with explicit descriptions, including examples and constraints, achieving 100% schema coverage. The description adds no additional parameter context, so it meets the baseline but does not enhance understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Query ServiceNow system properties', specifying the action and resource, which distinguishes it from sibling tools like get_record or get_ci. However, it does not explicitly contrast with alternatives or provide additional scope details, so it lacks the explicit differentiation seen in top-tier examples.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as get_record or list_records. It only states the basic action without mentioning exclusions, prerequisites, or typical use cases, leaving the agent to infer usage from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states 'Create a new record' without disclosing side effects, permission requirements, validation behavior, or implications of the 'any table' flexibility. No other behavioral traits are described.
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 a single, short sentence that is front-loaded with the action and scope. It is concise and to the point, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and generic scope, the description is too thin. It doesn't address required fields for the data object, error handling, or relationship to sibling tools like create_ci. The output schema may document returns, but the description itself leaves substantial gaps.
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 coverage is 100% with descriptions for both table_name and data. The tool description adds no extra parameter information beyond the schema, such as format expectations or required fields within the data object, so the baseline 3 applies.
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 action ('Create'), the object ('a new record'), and scope ('in any ServiceNow table'). This distinguishes it from sibling tools like update_record, delete_record, and get_record, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention that create_ci might be more appropriate for CI records, or that update_record is for modifying existing records, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only states the action without revealing side effects such as changing session state, affecting subsequent operations, or requiring special permissions. Nothing is said about reversibility or scope.
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 a single, front-loaded sentence that instantly communicates the tool's purpose. No wasted words or redundant attempts at scoping.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema and one well-documented parameter, the description omits critical context such as when this operation is needed, what it changes in the system, or how it interacts with other update set tools. Given no annotations, the description should compensate with more behavioral context.
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?
The input schema describes the only parameter (sys_id) and its purpose, achieving 100% schema description coverage. The description adds no additional meaning beyond what the schema already provides for this parameter.
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 uses a specific verb ('Set') and clearly identifies the resource ('update set') and the outcome ('current active update set'). It distinguishes itself from sibling tools like list_update_sets and create_update_set by focusing on changing the active context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. While the purpose implies changing the active update set, the description does not mention when a user would need this operation or what to use instead (e.g., create_update_set for new sets). The sibling tools provide context but the description itself offers no usage directions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It states 'Delete' but fails to reveal that deletion is permanent, whether it cascades, or whether special permissions are required. This is a destructive operation, and the absence of cautionary context is a significant gap.
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 a single, tightly crafted sentence that directly communicates the tool's purpose. Every word is necessary, and there is no redundancy or clutter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and the schema covers parameters, plus an output schema exists, so return values are not needed. However, as a deletion tool with no annotations, key contextual information such as irreversibility and potential side effects is omitted, leaving the description adequate but incomplete.
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?
The input schema provides 100% coverage with descriptions for both `sys_id` and `table_name`, so the baseline is 3. The description adds no additional parameter context, but the schema already carries the meaning effectively.
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 action ('Delete'), the resource ('a record from a ServiceNow table'), and the method ('by sys_id'). This unambiguously distinguishes it from sibling tools like get_record, create_record, and update_record.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor does it mention prerequisites or exclusions. No cross-references to sibling tools are given, leaving the agent without context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It states that the tool updates an existing record, which implies mutation, but does not disclose what happens if the sys_id is invalid, whether partial updates are supported, whether the operation is idempotent, or any authorization requirements. This is a minimal disclosure for a mutation tool.
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 a single sentence that is front-loaded with the key action and resource. It is appropriately sized for a simple CRUD tool, with no wasted words or redundant elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple and the input schema fully documents parameters; an output schema exists, so return values need not be explained. However, the description lacks behavioral context around error handling, record existence, or partial update semantics, and with no annotations this leaves some ambiguity. It is adequate but not rich.
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?
The input schema provides 100% coverage of all three parameters with meaningful descriptions (table_name, sys_id, data), so the description does not need to add parameter-level detail. The schema already explains that 'data' is a key-value payload of fields to update. The description adds no extra semantic value beyond the schema, warranting the baseline score.
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 uses a specific verb ('Update') and resource ('existing record in a ServiceNow table'), clearly distinguishing it from sibling tools like create_record, delete_record, and get_record. The scope is unambiguous and the action is immediately clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., existence of the record), exclusions, or scenarios where another tool like create_record or delete_record would be more appropriate. Usage must be inferred entirely from the name and sibling context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It does not state that this is a read-only operation, nor does it disclose any side effects, authentication requirements, or rate limits. Mentioning 'Stats API' is vague and does not clarify behavior.
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 a single, front-loaded sentence that efficiently conveys the core capability without fluff. Every word contributes to understanding the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return values are covered, but the tool has 9 parameters and is complex. The description lacks usage examples, caveats, or additional behavioral context. It is minimally adequate but leaves room for a more complete picture.
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 the input schema already documents all parameters with examples. The description adds no extra semantic meaning beyond listing function names that map to existing parameter descriptions, so baseline 3 applies.
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 aggregates records using specific operations (COUNT, AVG, MIN, MAX, SUM) with optional GROUP BY, distinct from sibling CRUD tools. The verb 'aggregate' and listed operations precisely define its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for aggregate statistical queries but does not explicitly state when to use it over list_records or get_record, nor does it mention exclusions. It relies on the reader to infer the use case from the word 'aggregate' and the API reference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only says 'List' and mentions filtering, without explaining read-only nature, pagination behavior, or any special side effects. The schema provides defaults but the description adds no behavioral context.
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 a single, front-loaded sentence with no redundant words. It efficiently conveys the tool's purpose and key capabilities.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has five parameters, no annotations, and an output schema. The description is minimal but the schema is rich, covering parameter details. However, it lacks guidance on when to use this vs list_records, which would help contextual completeness.
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 the baseline is 3. The description adds a high-level mention of 'class and query filtering,' but this is already detailed in the schema with examples. It does not significantly enhance parameter understanding.
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 lists CMDB configuration items, using a specific verb ('List') and resource ('CMDB configuration items'). This distinguishes it from sibling tools like get_ci (single CI) and list_records (generic records).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by naming the resource and filtering options, but it does not explicitly state when to use this tool over alternatives like list_records or get_ci. No when-not or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for behavioral disclosure. It only restates the purpose ('Get a single...') without adding context about read-only nature, error handling, authentication requirements, or return behavior. The description adds no information beyond the tool name and schema.
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 a single, clear sentence that front-loads the core action and key identifier. It contains no filler or repetition, earning every word.
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?
Given the tool's low complexity, the presence of an output schema, and full parameter documentation, the description provides sufficient information for an agent to invoke it correctly. It misses only optional usage context (e.g., when to prefer it over get_record), but the core function is adequately specified for this simple getter.
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?
The schema already covers both parameters with 100% description coverage, including the default for class_name. The description does not add any extra meaning about parameter syntax, constraints, or relationships beyond what the schema provides, so it holds baseline 3.
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 uses a specific verb ('Get') and resource ('single CMDB configuration item') with a clear key ('by sys_id'). It distinguishes from sibling tools like list_ci (multiple items) and get_ci_relationships (relationships), and clarifies it's CI-specific rather than generic get_record.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: use when you need a single CI and know its sys_id. However, it provides no explicit guidance on when not to use it or alternatives, such as preferring list_ci for queries or get_ci_relationships for linked items. The context is inferred rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states the basic action and does not mention read-only guarantees, potential errors (e.g., not found), permissions, or any side effects. The verb 'Get' gives a hint, but no additional context is provided.
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 a single, concise sentence that front-loads the core purpose. No unnecessary words or repetition of schema details.
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 three well-documented parameters and an output schema available, the description provides sufficient context for a simple getter. It is clear what the tool does, though it could add a brief pointer to alternatives for usage guidance. Overall, it is complete for a straightforward single-record retrieval tool.
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% for all three parameters. The tool description adds no extra meaning beyond the schema, but the schema itself is sufficient. Since schema covers all parameters, the baseline of 3 is appropriate.
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 specifies the action ('Get'), the resource ('a single record from a ServiceNow table'), and the method ('by sys_id'). It distinguishes from siblings like list_records (multiple records) and get_ci (specific CI records).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The word 'single' implies this is for fetching one record, contrasting with list_records for multiple. However, there is no explicit instruction on when to use this tool versus alternatives or any exclusions. Usage is implied rather than explicitly guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the burden of behavioral disclosure. It does not mention that this is a read-only operation, potential permissions required, pagination behavior (despite the 'limit' parameter), or any nuances about which changes are included (e.g., whether system updates are excluded). The description simply restates the tool's function without adding behavioral context.
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 a single, clear sentence with no redundancy or filler. It directly states the purpose and includes parenthetical clarification ('changes') to avoid ambiguity. Every word is necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity, the schema is complete and an output schema exists, so the description need not detail return values. However, the lack of annotations and absence of any behavioral context (e.g., read-only nature, pagination, or domain-specific meaning of 'customer updates') leaves the agent with only the literal function. It is minimally adequate but not comprehensive.
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?
The schema provides 100% coverage for both parameters (limit and update_set_sys_id), so the baseline is 3. The description does not add any further meaning beyond what the schema already says; 'within an update set' simply maps to update_set_sys_id without additional detail.
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 uses a specific verb ('List') and explicitly identifies the resource ('customer updates (changes)') and its context ('within an update set'). This clearly distinguishes it from sibling tools like list_update_sets, which list update sets themselves, and list_records, which is generic.
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 phrase 'within an update set' clearly signals the intended use case: when you have a specific update set and want its individual changes. While it does not explicitly mention alternatives, the context is unambiguous and the required update_set_sys_id parameter reinforces when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must convey behavior. It clarifies the scope to 'parent and child' relationships, but does not disclose any additional behavioral traits such as permissions, pagination, or error conditions.
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 a single sentence, front-loaded with the action and resource, and contains no redundant information.
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?
For a simple read operation with an output schema and fully described parameters, the description sufficiently covers the core functionality. It lacks usage guidance but the context is otherwise complete for this low-complexity tool.
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?
With 100% schema coverage, the schema already documents both sys_id and relation_type descriptions. The tool description adds no extra parameter semantics beyond that.
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 uses the specific verb 'Get' and identifies the resource as 'relationships for a CMDB configuration item (parent and child)', clearly distinguishing it from sibling tools like get_ci and list_ci.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use versus alternatives is provided. The phrase 'for a CMDB configuration item' implies the intended context but does not mention other relationship-related tools or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden, but it only states the core listing action and filtering options. It does not explicitly confirm read-only behavior or disclose any side effects, permissions, or pagination details beyond the schema. The verb 'list' implies safety, but extra context would help.
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 a single, front-loaded sentence with no filler. It efficiently conveys the essential purpose in 9 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?
For a straightforward list operation with no required parameters and a full output schema, the description covers the essential purpose and filtering capabilities. It doesn't add extra details, but none are critically needed for this low-complexity tool.
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?
The schema has 100% coverage for all 3 parameters, so the description adds little semantic value beyond restating that state and query filtering exist. It doesn't mention limit or provide syntax details beyond what the schema already documents; baseline 3 is appropriate.
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 specifies the action 'List' and the resource 'update sets', and notes optional state and query filtering, distinguishing it from sibling tools like get_update_set or list_update_set_changes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
While the description clearly implies this is the tool for listing update sets, it provides no explicit when-to-use versus alternatives (e.g., no mention of using get_update_set for a single set or list_records for other tables). The usage is understandable from context but not explicitly guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It transparently indicates a create operation, which is a mutation, but does not disclose permissions, success response behavior, side effects (e.g., whether the new update set becomes the current one), or any validation rules. This is minimal but not misleading.
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 a single, front-loaded sentence with no filler or redundancy. It states the action ('Create'), the resource ('update set'), and the purpose ('tracking customizations') economically.
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?
Given the tool's simplicity (3 params, 1 required, output schema present), the description is largely complete. It explains the purpose and creates enough context for an agent. It could optionally note that 'parent' enables batch sets, but the schema already handles this. The description is sufficient for a straightforward create tool.
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?
The schema description coverage is 100%, so the baseline is 3. The description adds no parameter-specific meaning beyond the schema, but the schema already fully documents name, parent (with note about batch sets), and description. Thus, the description does not need to compensate for missing parameter info.
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 states 'Create a new update set for tracking customizations', which uses a specific verb and resource, clearly distinguishing it from sibling tools like create_record (generic creation) and get_update_set (read). The scope is explicitly stated with the purpose 'for tracking customizations'.
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 phrase 'Create a new update set' clearly indicates when to use this tool, but it does not explicitly exclude alternatives or mention when not to use it relative to sibling tools like set_current_update_set or create_record. The context is clear enough for an agent to infer that this is for creating new update sets, not for updating or listing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It conveys that the operation is a read ('Get') and scopes it to the 'currently authenticated user', which is useful context. However, it does not detail any side-effects, permission requirements, or limitations beyond the scope.
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 a single, front-loaded sentence with no redundant words or filler. Every word contributes to understanding the tool's purpose.
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?
Given the tool's simplicity, a known output schema, and a well-documented parameter, the description is adequate. It could add a note about the return shape or that it requires authentication, but the schema and tool name already cover most expectations.
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?
The single parameter 'fields' is fully documented in the input schema with 100% coverage, including its default value. The description adds no additional parameter semantics, but the schema already provides the necessary details, so the baseline score of 3 is appropriate.
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 uses a specific verb ('Get') and resource ('currently authenticated user's information'), making its purpose unmistakable. It clearly distinguishes from sibling tools like get_record or get_ci by focusing on the authenticated user context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when you need the current user's information) but does not explicitly compare it with alternatives like get_record or list_records. No exclusions or prerequisite conditions are mentioned, so usage context is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It states that it retrieves details, which implies a read-only operation, but does not disclose any additional behavior such as error handling, permissions, or that it returns the full record. The existence of an output schema covers the return format, so a moderate score is appropriate.
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 a single, succinct sentence that conveys all necessary information without any fluff or redundancy. Every word contributes to clarifying the tool's purpose.
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?
Given the low complexity (single parameter, output schema present), the description is nearly complete. It clearly identifies the target object and the required identifier, leaving no critical gaps for a getter operation. The only minor shortfall is lacking explicit mention of what 'details' entails, but the output schema covers that.
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?
The schema already provides 100% coverage with a clear description for sys_id. The tool description merely restates 'by sys_id' without adding any new meaning beyond what the schema offers, so the baseline score of 3 applies.
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 uses a specific verb ('Get') and resource ('update set'), and identifies the key parameter ('sys_id'). This clearly differentiates it from sibling tools like list_update_sets or set_current_update_set, which serve different purposes.
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 clearly implies the tool is for retrieving a single, specific update set using its sys_id. It provides sufficient context to distinguish it from listing or creating update sets, though it does not explicitly mention when not to use it or name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the reading behavior and optional capabilities (filtering, field selection, pagination) but does not explicitly state read-only nature, default limits, or error behavior. It adds some context but lacks depth.
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 a single 13-word sentence, front-loaded with 'List records'. Every word contributes meaning, and no extraneous or redundant information appears. It is an exemplar of conciseness.
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?
For a simple list tool with a comprehensive schema and an output schema present, the description is complete enough. It covers the core purpose and options. Missing explicit mention of defaults or edge cases is minor because the schema provides those details.
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% for all six parameters, so the baseline is 3. The description mentions filtering, field selection, and pagination, which maps to query, fields, limit/offset, but adds no additional detail beyond the schema's own descriptions. It neither compensates nor detracts.
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 a specific verb 'List' and resource 'records from any ServiceNow table', with optional filtering, field selection, and pagination. This distinguishes it from sibling tools like get_record (which implies single-record retrieval) and mutation tools like create/update/delete.
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: it lists records from any table with optional filtering, field selection, and pagination, which implies use for multi-record queries. It does not explicitly name alternatives or exclusion criteria, but the context is sufficient for an agent to select it over singular or aggregate tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full transparency burden. It clarifies the read-only nature implicitly via 'Get' and explains the result semantics (field definitions), but it does not disclose any potential side effects, permission requirements, or error behaviors. Given the output schema exists, some burden is reduced, but the lack of explicit safety information makes this a minimum viable score.
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 a single, front-loaded sentence that directly states the purpose with no filler or redundancy. Every word earns its place, making it an exemplary model of conciseness.
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?
This is a simple read-only tool with a small parameter set, full schema coverage, and an output schema. The description fully answers what the tool does and what it returns. No additional context is needed for a tool of this simplicity.
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 both parameters are already documented. The description adds minimal semantic value beyond the schema, only confirming that the table is a ServiceNow table and that the result is field definitions. This matches the baseline score of 3 for fully covered schemas.
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 uses a specific verb ('Get') and resource ('data dictionary (field definitions) for a ServiceNow table'), clearly distinguishing it from sibling tools that operate on records, CIs, or update sets. This leaves no ambiguity about what the tool does.
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 context is clear: this tool is for retrieving schema metadata, not data. The sibling tools (list_records, get_record, etc.) are obviously for record-level operations, so a user would naturally choose this when needing field definitions. However, the description does not explicitly state when to use it over alternatives or mention any exclusions, stopping short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![mcp-server-servicenow MCP server](https://glama.ai/mcp/servers/jschuller/mcp-server-servicenow/badges/card.svg)](https://glama.ai/mcp/servers/jschuller/mcp-server-servicenow)

Score Badge

Copy to your README.md:

[![mcp-server-servicenow MCP server](https://glama.ai/mcp/servers/jschuller/mcp-server-servicenow/badges/score.svg)](https://glama.ai/mcp/servers/jschuller/mcp-server-servicenow)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/jschuller/mcp-server-servicenow'

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