servicenow-platform-mcp

by Xerrion

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.10.0
Disambiguation4/5
Most tools have distinct purposes (e.g., query vs. record_read, attachment vs. attachment_write). Minor overlap between query and record_read could cause confusion, but descriptions help differentiate.
Naming Consistency3/5
Tool names follow mixed conventions: some verb-based (audit, describe), some noun-based (flow, service_catalog), and compound patterns (record_read, build_query). Inconsistent but still readable.
Tool Count5/5
14 tools is well-scoped for the ServiceNow platform, covering key areas (attachments, records, queries, catalog, flow, investigations) without being overwhelming.
Completeness4/5
Covers CRUD for records, attachments, query building, and catalog operations. Lacks higher-level automation tools like business rule management, but core workflows are supported.
Average 4.2/5 across 14 of 14 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 10 commits in the last 12 weeks
- Last stable release on May 29, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
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?
The description lacks disclosure of behavioral traits such as idempotency, side effects (e.g., order_now is likely destructive), or required permissions. No annotations exist to compensate. While actions like 'catalogs_list' are read-only, actions like 'cart_checkout' imply write operations, but this is not clarified.
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?
The description is well-structured with a clear opening line and a bullet list of parameters. It is reasonably concise given the complexity of 11 parameters and multiple actions. Minor redundancy exists (e.g., repeating action names in parameter explanations), but overall it is efficient.
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 tool with 11 parameters and many actions, the description covers most critical usage aspects: parameter-action mappings and defaults. Since an output schema exists, the lack of return value descriptions is acceptable. However, ordering constraints or pagination details could be more explicit.
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?
The input schema has no parameter descriptions (0% coverage), but the description adds meaningful context by explicitly listing which parameters apply to which actions (e.g., sys_id for catalog_get). This significantly compensates for the schema gap, though a few parameters like 'variables' could have more detail on format.
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 that this tool handles Service Catalog operations by dispatching on an 'action' parameter. It enumerates specific actions like catalogs_list and order_now, making the resource explicit. However, it does not differentiate from sibling tools like 'query' or 'record_read', which might also handle catalog-related data.
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. The description simply lists actions without indicating preferred use cases or dependencies. Given the sibling tools (e.g., 'query', 'record_read'), explicit guidance on when to use this dispatcher would improve clarity.
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 provided. The description lacks disclosure of side effects (e.g., deletion permanence), permission requirements, or error behavior. It only explains parameter usage.
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 concise, front-loaded with the core purpose, and uses a clear bullet-like list for arguments. No redundant information.
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 description covers parameter semantics adequately but lacks higher-level context such as success/failure responses or limitations. With output schema present, return values may be addressed externally.
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?
The description compensates for 0% schema coverage by explaining each parameter's role and conditionally grouping them under upload or delete actions. This adds significant meaning beyond the schema titles.
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 'Write attachments' and specifies two actions: 'upload' and 'delete'. This distinguishes it from sibling tool 'attachment' which likely reads attachments.
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 on when to use upload vs delete, nor prerequisites or alternatives. The description only lists parameters without usage context.
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?
The description discloses the basic read operation but provides no details on authentication requirements, potential rate limits, or any side effects. With no annotations, more behavioral context would be helpful, but the simplicity of a list operation mitigates the 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 sentence with no unnecessary words. It is front-loaded with the action and resource, making it easy to parse.
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 simplicity of the tool (no parameters, no annotations, output schema exists), the description is minimally sufficient. However, it could clarify what 'tool packages' and 'tool groups' are or if any preconditions exist.
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?
The input schema has zero parameters, so schema coverage is 100%. The description does not need to add parameter meaning; the baseline score of 4 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 states the action ('List') and the resource ('all available tool packages and their tool groups'). It distinguishes from sibling tools like 'query' or 'record_read' which have 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. There is no mention of prerequisites, context, or exclusions, leaving the agent to infer usage solely 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey behavioral traits. It indicates read-only operation ('Read attachments') but does not disclose idempotency, authentication needs, rate limits, or side effects. The transparency is adequate but not comprehensive.
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 concise, using a clear list format for actions and parameters. Every sentence adds value, and there is no extraneous text.
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 complexity (5 parameters, no annotations, output schema exists), the description sufficiently covers the action types and parameter mappings. It does not explain return values (handled by output schema), but could benefit from more context on when each action is appropriate.
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?
The input schema has 0% description coverage, but the tool description compensates well by explaining each parameter's purpose (e.g., 'sys_id: Attachment sys_id (for get, download)'). This adds significant meaning beyond the raw schema fields.
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 'Read attachments' and enumerates specific actions (list, get, download, download_by_name), making the tool's purpose unambiguous and distinguishing it from the sibling tool 'attachment_write'.
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 via the action parameter but provides no explicit guidance on when to choose this tool over siblings like 'attachment_write' or when not to use it. There is no mention of prerequisites or alternatives.
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?
Explicitly labels the tool as read-only. Describes mutually exclusive parameters and action-specific behavior. Without annotations, the description covers key behavioral traits, though it omits side effects or permissions.
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?
Concise and well-structured: starts with overall purpose, then bullet-like list of arguments. No redundant information.
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?
Covers all 8 parameters, multiple actions, and mutual exclusion. Since an output schema exists, the description sufficiently completes the context needed for invocation.
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?
Adds meaningful explanations for each parameter beyond the schema (e.g., 'mutually exclusive with name', 'gzip+base64+JSON blob'). The schema coverage is 0%, so the description compensates well, though it could clarify default values.
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?
Clearly states the tool inspects Flow Designer flows, triggers, and value blobs in a read-only manner. The description is specific to this tool but does not explicitly differentiate it from siblings like 'query' or 'record_read'.
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?
Provides detailed parameter explanations but lacks guidance on when to use this tool versus alternatives. No explicit when-not-to-use or exclusion conditions.
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 details the three modes and their parameters but does not disclose side effects, permissions, idempotency, or latency. It adequately explains behavior but lacks deeper context.
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?
The description is well-structured with clear argument breakdowns and examples. It is concise (4 sentences plus list) and front-loaded with the purpose, though the 'Args:' block could be slightly more streamlined.
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 4 parameters and no schema descriptions, the description covers all parameter behavior and action modes. An output schema exists, so return values are not needed. Minor gaps like error handling or default action behavior remain.
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%, so the description fully compensates by explaining each parameter: action's three values, name with list of available investigations, params as JSON string, and element_id format. This adds significant meaning beyond the schema.
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 'Run an investigation or explain a finding,' specifying three distinct actions (run, explain, describe). It differentiates from sibling tools like 'describe' and 'query' by listing specific investigation names (e.g., stale_automations, deprecated_apis), making it precise.
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 provides guidelines for when to use each action (run requires name, explain requires element_id, describe takes optional name) but does not explicitly state when not to use this tool or compare it to siblings like 'query' or 'audit'.
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 explains the conditional behavior (returns mapping if label empty) but does not disclose error handling, authentication requirements, or rate limits. The read-only nature is implied but not explicitly stated.
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 concise with only three sentences, front-loading the purpose and listing parameters efficiently. No unnecessary 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?
Given the tool's simplicity and the existence of an output schema, the description covers key behaviors. It could mention the output format more explicitly, but overall it is sufficiently complete for an agent to use 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?
Despite schema description coverage being 0%, the description explicitly explains each parameter: 'ServiceNow table name', 'Field name on that table', and the special behavior of the label parameter when empty. This adds significant meaning beyond the schema.
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: resolving a choice label to its underlying value via ChoiceRegistry. It also distinguishes from siblings by specifying a unique function not shared by other tools in the list.
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 resolving choice labels and optionally getting the full mapping when label is empty. However, it does not provide explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives among siblings.
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 full responsibility for behavioral disclosure. It explicitly explains key behaviors: if sys_id is set, other filters are ignored; fields empty returns all with masking; aggregate mode returns aggregate results; resolve_labels modifies encoded_query. It does not cover error handling or rate limits, but the known behaviors are well-documented.
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?
The description is structured with a clear one-line summary followed by an 'Args' section that bullet-points each parameter. While lengthy (about 15 lines), every sentence provides necessary detail. It is front-loaded efficiently, but minor redundancy in examples could be trimmed slightly.
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 (11 parameters, output schema exists), the description covers all key behaviors: parameter interactions (sys_id mode, aggregate mode), defaults, constraints (max rows), and special features (resolve_labels). Since output schema exists, return values need not be explained. The description is complete for an AI agent to use correctly.
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 schema description coverage is 0%, so the description must explain all parameters. It does so thoroughly: each parameter is described with its effect, special conditions (e.g., sys_id ignoring other filters), and examples (e.g., order_by with '-' prefix, aggregate functions). This adds substantial meaning beyond the schema's basic types and defaults.
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 'Read records, aggregates, or a single record from any ServiceNow table', identifying the specific verb and resource. It distinguishes itself from siblings like 'record_read' and 'record_write' by emphasizing the ability to perform aggregated queries and use encoded queries, making its purpose distinct.
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 does not provide explicit guidance on when to use this tool versus siblings such as 'record_read' or 'investigate'. It implies usage through parameter details (e.g., when to use sys_id vs encoded_query) but lacks a clear 'when-to-use' or 'when-not-to-use' statement, leaving the agent to infer context.
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?
Without annotations, it discloses key behavior: the token is single-use and consumed on success or failure, indicating idempotency and ensuring the agent understands the token's lifecycle.
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?
Two short sentences plus a bullet, no fluff, purpose is front-loaded. Every word adds value.
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 commit tool with one parameter and an output schema, the description covers the essential behavior and usage. Minor gaps in error details, but overall sufficient.
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?
With 0% schema description coverage, the description compensates by explaining the preview_token parameter's origin and single-use nature, adding crucial context beyond the schema.
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 explicitly states 'Commit a previously previewed write', using a specific verb ('commit') and resource ('previewed write'), differentiating it from siblings like 'record_write' which handles previews.
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?
It clearly states to use after a preview with record_write, and specifies the token origin. Though it does not explicitly list when not to use, the context is sufficient.
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?
No annotations provided, so the description carries full burden. It explains the input structure and output, but does not disclose error handling, validation, or performance characteristics. Still, it is thorough for a transformation tool.
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?
The description is well-structured with bullet points and sections, front-loading the purpose. It is detailed but could be slightly more concise without losing clarity. Every sentence adds value.
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?
With only one parameter but complex structure, the description covers all necessary details: operator groups, required fields for each, and the return format. It is fully self-contained for an agent to use the tool correctly.
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 0% description coverage, but the tool description provides an extensive explanation of the 'conditions' parameter, including allowed operator groups, required fields, and examples. This fully compensates for the schema gap.
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 it builds a ServiceNow encoded query string from a JSON array of conditions. It differentiates from the sibling 'query' tool by explicitly noting the output should be passed as the query parameter to that tool.
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 explicitly states the output should be passed to the 'query' tool, providing clear context. However, it does not explicitly state when not to use this tool or list 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral burden. It discloses that sensitive fields are masked, the script_fields list is dynamically resolved, and ambiguous name matches return an error. This provides sufficient transparency for a read operation.
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 concise, front-loaded with the main purpose, and structured with an Args section for clarity. Every sentence adds value without redundancy.
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 presence of an output schema (not shown but indicated), the description need not cover return values. It adequately covers input constraints, behavioral nuances (masking, script_fields), and error conditions. A small gap is the lack of mention of rate limits or authentication, but these are acceptable omissions for a read tool.
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 schema has 0% description coverage, so the description must compensate. It does so by explaining the purpose of each parameter: table is the ServiceNow table, sys_id and name are mutually exclusive lookup keys, and name resolves via query with error on ambiguity. This adds significant meaning beyond the raw schema.
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 'Fetch a record by sys_id or name from any table,' which is a specific verb+resource. It distinguishes itself from sibling tools like record_write (write) and query (list/search) by focusing on single-record fetch.
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 explicitly states that exactly one of sys_id or name must be supplied, and explains the mutual exclusivity. It also provides context about tables with zero script fields. However, it does not explicitly compare to alternatives like query or record_write, which would help the agent decide when to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses behavioral traits: the deny-list of high-noise keys in verbose mode, the requirement of table for list_script_fields, and the flow differences for the action parameter. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is fairly long but structured logically: first sentence states the dual purpose, then parameter details. It is front-loaded. Could be slightly more concise, but every sentence adds value.
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 5 parameters, no required ones, and presence of output schema, the description provides sufficient context for using the tool. It explains return structure indirectly but adequately. Slight gap: does not explicitly mention pagination or limits, but for metadata retrieval it may be complete.
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%, but the description adds extensive meaning to each parameter beyond type/defaults. It explains what 'fields', 'verbose', 'include_docs', and 'action' do, including nuanced behaviors (e.g., empty fields = all fields).
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 returns slim field metadata for a table, with an alternative mode to list script-bearing fields. It uses specific verbs ('Return', 'list') and distinguishes itself from sibling tools like query or record_read by focusing on metadata rather than data.
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 explains parameter usage in detail, including the requirement for 'table' even with 'action', and the effect of each parameter. While it does not explicitly state when not to use the tool or list direct alternatives, the context from sibling tools implies appropriate use cases.
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, the description carries full burden. It explains that the tool inspects posture and trail, and warns about performance implications of wide windows. However, it doesn't explicitly state whether the tool is read-only or if it modifies data, though 'inspect' implies read-only.
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?
Description is well-structured with a brief intro, an important warning, and a clear Args list. It is informative but not overly verbose. Could be slightly more concise by removing redundant 'required for' phrasing, but overall effective.
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 complexity (8 parameters, 5 actions), the description covers all necessary usage and constraints. An output schema exists (not shown) which would further help, but the description itself is complete enough for an agent to understand behavior and invocation.
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?
Input schema has 0% description coverage, but the description provides detailed explanations for all 8 parameters including the allowed action values, required fields for each action, and constraints like 1..50 for fields_csv and 32-char sys_id. This adds significant meaning beyond the schema.
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?
Description clearly states 'Inspect ServiceNow audit posture (table/field config) and audit trail.' This is a specific verb-resource combination that distinguishes it from sibling tools like query (which retrieves records) and record_read (reads specific records).
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?
Provides explicit guidance on when to use the tool and when to be cautious: warns about sys_audit table size, default 90-day window, and advises to override window_days or since only when necessary. Also implicitly differentiates from siblings by focusing on audit trail vs general querying.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It comprehensively discloses behavior: default preview mode, script-path resolution (strict, max 1 MB, XML validation), field detection via sys_dictionary, error behavior for script_field, and preview token workflow. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a brief overview followed by an Args block, but it includes technical details (e.g., super_class chain, sys_dictionary row order) that could be streamlined. Still, it is efficient for a complex tool with 7 parameters.
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 (7 parameters, script handling, preview mode) and the presence of an output schema, the description covers all input-related aspects thoroughly. It explains edge cases like script-field discovery and error handling. The output schema is not detailed, but that is acceptable per rules.
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%, so the description must compensate. It provides an 'Args' section that explains each of the 7 parameters in detail, including defaults, requirements, and behavior. This adds significant meaning beyond the bare schema.
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 'Create, update, or delete a record' with a specific verb and resource. It distinguishes from siblings like record_read and record_apply by mentioning preview mode and the need for record_apply to commit. The tool's role as a write operation is unambiguous.
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 context for when to use the script-related parameters and mentions preview mode, but does not explicitly state when to use this tool versus alternatives like record_read or query. However, the tool's purpose is clear from sibling names, so the gap is minor.
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:

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

Score Badge

Copy to your README.md:

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

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/Xerrion/servicenow-platform-mcp'

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