ServiceNow MCP Server

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Most tools have distinct purposes targeting specific ServiceNow resources and actions, with clear boundaries like create_incident vs. resolve_incident. However, some overlap exists between catalog-related tools (e.g., create_catalog_category vs. update_catalog_category) and knowledge base tools (list_articles vs. get_article), which could cause minor confusion but descriptions help differentiate them.
Naming Consistency5/5
Tool names follow a highly consistent verb_noun pattern throughout, such as create_incident, list_users, update_workflow, and get_change_request_details. All tools use snake_case with clear action-object naming, making them predictable and easy to understand without any deviations in convention.
Tool Count2/5
With 66 tools, the count is excessive for typical MCP server scopes, making it feel heavy and potentially overwhelming for agents. While ServiceNow is a broad platform, this many tools suggests poor scoping or fragmentation, as many operations could be consolidated into fewer, more general tools.
Completeness5/5
The tool set provides comprehensive CRUD and lifecycle coverage across multiple ServiceNow domains, including incidents, change requests, knowledge bases, workflows, and users. It includes all essential operations from creation to deletion, with no obvious gaps, ensuring agents can handle full workflows without dead ends.
Average 2.5/5 across 66 of 66 tools scored. Lowest: 1.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It only states the action 'update' without indicating whether this is a mutation, what permissions are required, if changes are reversible, or what the response looks like. For a tool that modifies data, this lack of transparency is critical.
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 a single, straightforward sentence that is front-loaded with the core action. There's no unnecessary verbiage, making it efficient. However, its brevity contributes to underspecification rather than optimal clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of updating a catalog item variable with 1 required parameter and multiple optional fields, no annotations, and no output schema, the description is severely incomplete. It fails to explain what the tool does beyond the basic verb, leaving the agent without necessary context for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning parameters are undocumented in the schema. The description adds no information about parameters beyond implying an update action. It doesn't mention the required 'variable_id' or optional fields like 'label' or 'mandatory', leaving the agent unable to understand what inputs are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update a catalog item variable' restates the tool name with minimal elaboration. It specifies the verb 'update' and resource 'catalog item variable', but lacks detail on what a catalog item variable is or what aspects can be updated. Compared to siblings like 'update_catalog_item' or 'update_workflow_activity', it doesn't differentiate scope or functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 doesn't mention prerequisites (e.g., needing a variable_id), when not to use it, or related tools like 'create_catalog_item_variable' or 'list_catalog_item_variables'. This leaves 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.
Behavior1/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 but offers none. It doesn't indicate whether this is a read-only or destructive operation, what permissions are required, whether it triggers workflows, what happens on success/failure, or any rate limits. The description fails to provide any behavioral context beyond the basic creation action.
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 maximally concise at a single sentence with no wasted words. It's front-loaded with the core action and resource. While severely under-specified, what's present is structured efficiently without redundancy or unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a ServiceNow changeset creation tool with no annotations, no output schema, and poor schema description coverage, this description is completely inadequate. It doesn't explain what a changeset is, how it relates to other change management entities, what happens after creation, or what the tool returns. The description fails to provide the minimal context needed for effective tool use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides zero information about parameters, while the input schema has 0% description coverage (the schema descriptions are generic like 'Name of the changeset'). With 1 required parameter (a nested object containing 4 fields), the description doesn't explain what 'params' contains, what 'application' refers to, or the relationship between name, description, application, and developer fields. It fails to compensate for the schema's lack of semantic detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a new changeset in ServiceNow' is a tautology that essentially restates the tool name 'create_changeset' with minimal additional context. It specifies the verb 'create' and resource 'changeset' but provides no detail about what a changeset is, its purpose, or how it differs from similar resources like change requests or workflows mentioned in the sibling tools list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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. With sibling tools like 'create_change_request', 'commit_changeset', 'publish_changeset', and 'update_changeset', there's no indication of the workflow context, prerequisites, or sequencing relationships. The agent receives no help in distinguishing this tool's role in the broader ServiceNow change management process.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It only states the action 'list' without any information about permissions, rate limits, pagination behavior, error conditions, or output format. For a tool with parameters and no output schema, this leaves critical behavioral aspects undocumented, failing to compensate for the lack of annotations.
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 extremely concise with a single, direct phrase. There is no wasted language or unnecessary elaboration, making it front-loaded and efficient. However, this conciseness comes at the cost of completeness, as it under-specifies critical details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, no output schema, no annotations), the description is severely incomplete. It lacks purpose differentiation, usage guidelines, behavioral transparency, and parameter semantics. This leaves the agent with insufficient information to understand what the tool does, how to use it, or what to expect, making it inadequate for effective tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning parameters are undocumented in the schema. The description provides no information about parameters, not even mentioning the required 'catalog_item_id' or optional ones like 'limit' and 'offset'. It fails to compensate for the schema gap, leaving all parameter meanings and usage unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List catalog item variables' is a tautology that restates the tool name with minimal elaboration. It specifies the verb 'list' and resource 'catalog item variables', but lacks any distinguishing details about scope, format, or relationship to sibling tools like 'get_catalog_item' or 'create_catalog_item_variable'. This provides only basic purpose without meaningful differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 does not mention prerequisites, context, or comparisons to sibling tools such as 'get_catalog_item' (which might retrieve item details including variables) or 'update_catalog_item_variable'. Without any usage context, the agent has no basis for selecting this tool appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure but offers none. It doesn't indicate if this is a mutation (likely, given 'publish'), what permissions are required, if it's idempotent, what happens on success/failure, or any side effects (e.g., notifications). The single sentence lacks critical operational 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, efficient sentence with zero wasted words. It's front-loaded and appropriately sized for its minimal content, though this conciseness comes at the cost of completeness. Every word earns its place by stating the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (a mutation tool with 3 parameters), no annotations, no output schema, and 0% schema description coverage, the description is severely incomplete. It fails to explain what publishing does, parameter roles, behavioral traits, or expected outcomes, making it inadequate for safe and effective use by an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/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 but adds no parameter information. It doesn't mention the required 'article_id' or optional 'workflow_state' and 'workflow_version' parameters, their purposes, or how they interact (e.g., default state 'published'). This leaves all parameters undocumented beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Publish a knowledge article' restates the tool name 'publish_article' with minimal elaboration, making it tautological. It specifies the verb 'publish' and resource 'knowledge article', but lacks specificity about what publishing entails (e.g., making it live, changing workflow state) and doesn't distinguish it from sibling tools like 'update_article' or 'create_article'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 doesn't mention prerequisites (e.g., article must exist), differentiate from similar tools (e.g., 'update_article' might also affect publication), or specify contexts (e.g., only for draft articles). This leaves the agent with no usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure but offers none. It doesn't indicate whether this is a destructive/mutative operation (implied by 'reject' but not explicit), what permissions are required, what happens after rejection (e.g., status change, notifications), or any error conditions. For a tool that likely modifies system state, this is critically inadequate.
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 maximally concise at just four words. While this represents severe under-specification rather than ideal conciseness, from a pure structural perspective it's front-loaded with the core action and contains no wasted words. Every word earns its place, even though that place is insufficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a state-changing operation like rejecting a change request, no annotations, no output schema, and 0% schema description coverage, the description is completely inadequate. It doesn't explain what the tool does beyond the name, when to use it, what parameters mean, what happens after rejection, or what the response contains. This leaves the agent with minimal actionable information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides zero information about parameters, while the schema description coverage is 0% (parameter descriptions like 'Change request ID or sys_id' come from the schema, not the tool description). With 1 required parameter (a nested object with 3 fields) and no parameter guidance in the description, the agent must rely entirely on the schema without any contextual explanation of what 'rejecting' actually requires.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Reject a change request' is a tautology that essentially restates the tool name 'reject_change' without adding meaningful specificity. While it identifies the verb ('reject') and resource ('change request'), it doesn't distinguish this from sibling tools like 'approve_change' or provide any context about what rejecting entails beyond the obvious meaning of the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides absolutely no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., that a change request must be in a specific state), exclusions, or relationships to sibling tools like 'approve_change', 'submit_change_for_approval', or 'update_change_request'. This leaves the agent guessing about proper context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. 'Reorder activities in a workflow' implies a mutation operation but fails to describe critical aspects: whether it requires specific permissions, if it's destructive to existing data, what happens to activities not listed, error conditions, or the response format. This leaves significant gaps in understanding the tool's 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, clear sentence with no wasted words, making it highly concise and front-loaded. Every word contributes directly to stating the tool's purpose, achieving optimal efficiency in structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a mutation tool with no annotations, 0% schema coverage, and no output schema, the description is severely incomplete. It lacks behavioral details, parameter explanations, usage context, and output information, making it inadequate for an agent to correctly invoke this tool without significant guesswork.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning parameters are undocumented in the schema. The description adds no information about parameters beyond what's implied by the tool name. It doesn't explain 'workflow_id' or 'activity_ids' (e.g., format, source, or that 'activity_ids' must be a complete reordered list), failing to compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Reorder activities in a workflow' clearly states the verb ('reorder') and resource ('activities in a workflow'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'add_workflow_activity' or 'delete_workflow_activity' beyond the basic action, lacking specificity about what distinguishes this reordering operation.
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 doesn't mention prerequisites (e.g., needing an existing workflow), exclusions, or comparisons to siblings like 'update_workflow_activity' or 'get_workflow_activities', leaving the agent with no contextual usage information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It states this is an update operation but reveals nothing about permissions required, whether changes are reversible, rate limits, or what happens to unspecified fields. For a mutation tool with zero annotation coverage, this is a critical 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, efficient sentence with zero wasted words. It's appropriately sized for a basic tool definition and front-loads the core purpose without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a mutation tool with 6 parameters, 0% schema description coverage, no annotations, and no output schema, the description is completely inadequate. It doesn't explain what fields can be updated, behavioral implications, or expected outcomes, leaving the agent with insufficient information to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, meaning none of the 6 parameters (article_id, title, text, short_description, category, keywords) have descriptions in the schema. The tool description adds no parameter information beyond what's implied by 'update an existing knowledge article.' It fails to compensate for the complete lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update an existing knowledge article' clearly states the verb ('update') and resource ('knowledge article'), but it's vague about what specific aspects can be updated and doesn't distinguish this tool from sibling update tools like update_catalog_category or update_change_request. It provides basic purpose but lacks specificity.
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 doesn't mention prerequisites (e.g., needing an existing article), differentiate from create_article, or specify appropriate contexts. The agent must infer usage from the tool 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 carries the full burden of behavioral disclosure. While 'Create' implies a write operation, the description doesn't specify permissions required, whether the creation is idempotent, what happens on conflicts (e.g., duplicate names), or what the response contains. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
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 extremely concise with a single sentence, 'Create a new catalog item variable', which is front-loaded and wastes no words. While it may be too brief for completeness, it scores high on conciseness as it avoids redundancy and gets straight to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of creating a catalog item variable (implied by the detailed nested schema with 14 properties), no annotations, no output schema, and 0% schema description coverage, the description is completely inadequate. It fails to explain parameters, behavior, or output, leaving the agent with insufficient context to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides no information about parameters, while the input schema has 1 parameter ('params') with 0% description coverage in the schema itself (the schema's description field is empty). This leaves all parameter details undocumented, making it unclear what 'params' should contain or how to structure the request.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a new catalog item variable' clearly states the action (create) and resource (catalog item variable), but it's somewhat vague about what a 'catalog item variable' entails in this context. It doesn't differentiate from sibling tools like 'update_catalog_item_variable' or 'list_catalog_item_variables', leaving room for confusion about when to use each.
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. There are multiple sibling tools related to catalog item variables (e.g., 'list_catalog_item_variables', 'update_catalog_item_variable'), but the description doesn't mention any prerequisites, dependencies, or scenarios where this tool is appropriate versus others.
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 carries the full burden of behavioral disclosure. It states 'Add a task' which implies a write/mutation operation, but it doesn't disclose any behavioral traits such as required permissions, whether the task is automatically activated, what happens on failure, or if there are rate limits. The description is minimal and lacks critical context for safe and effective use.
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, straightforward sentence: 'Add a task to a change request.' It's front-loaded with the core action and resource, with zero wasted words. Every part of the sentence is essential to conveying the basic purpose, making it highly concise and well-structured for its minimal content.
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?
Given the complexity (a mutation tool for adding tasks), lack of annotations, no output schema, and 0% schema description coverage, the description is incomplete. It doesn't explain what the tool returns, error conditions, or behavioral nuances. While concise, it fails to provide enough context for an AI agent to use the tool effectively without guesswork.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides no information about parameters beyond what's implied by the tool name. With a parameter count of 1 (a nested object 'params'), schema description coverage is 0%, meaning the schema's properties (like 'change_id', 'short_description') are undocumented in both the schema and description. The description fails to compensate for this gap, leaving parameters semantically unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Add a task to a change request' clearly states the verb ('add') and resource ('task'), but it's somewhat vague about the specific action—it doesn't specify whether this creates a new task record, assigns an existing task, or triggers a workflow. It distinguishes from obvious non-siblings like 'get_change_request_details' but doesn't explicitly differentiate from closer siblings like 'update_workflow_activity' or 'create_change_request' in terms of scope.
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 doesn't mention prerequisites (e.g., needing an existing change request), exclusions (e.g., not for updating tasks), or related tools like 'create_change_request' for initial setup or 'update_workflow_activity' for modifying tasks. Usage is implied only by the name and description, with no explicit 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 provided, the description carries the full burden of behavioral disclosure. It only states the action ('Get detailed information') without mentioning permissions required, rate limits, error handling, or what 'detailed information' entails (e.g., fields returned, format). This leaves critical behavioral traits unspecified 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, straightforward sentence that is front-loaded with the core purpose. It avoids unnecessary words, making it efficient, though it could benefit from additional context to improve utility without sacrificing brevity.
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?
Given the complexity of a read operation with no annotations, 0% schema coverage, and no output schema, the description is incomplete. It doesn't cover parameter details, return values, or behavioral aspects, leaving significant gaps for an AI agent to understand and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the input schema provides no descriptions for parameters. The description adds no parameter semantics beyond implying a 'change_id' is needed, but it doesn't explain what a 'change request ID or sys_id' is, its format, or where to find it. This fails to compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool's purpose as 'Get detailed information about a specific change request', which includes a verb ('Get') and resource ('change request'), making it clear what it does. However, it doesn't distinguish it from sibling tools like 'get_changeset_details' or 'get_workflow_details', leaving ambiguity about scope.
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. For example, it doesn't clarify if this is for retrieving a single change request by ID versus using 'list_change_requests' for multiple items, or how it differs from other 'get_' tools. This lack of context makes usage decisions difficult.
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 but offers minimal information. It states the action ('List') but doesn't describe whether this is a read-only operation, what permissions might be required, how results are returned (e.g., pagination behavior beyond the schema's limit/offset), or potential side effects. For a tool with multiple parameters and no annotation coverage, this lack of behavioral 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 extremely concise at just three words, with zero wasted language. It's front-loaded with the core action and resource, making it easy to parse quickly. While this conciseness comes at the cost of detail, the structure is optimal for minimal text—every word earns its place by conveying essential information without redundancy.
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?
Given the complexity (6 sub-parameters in a nested object, no output schema, and no annotations), the description is incomplete. It doesn't address how results are structured, what filtering options exist beyond the schema, or behavioral aspects like pagination or permissions. For a list operation with multiple filtering parameters, the description should provide more context about usage and expected outcomes to be adequately helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides no information about parameters, while the schema description coverage is 0% (the schema has descriptions for individual parameters, but the overall coverage metric is given as 0%). With 1 parameter (a nested object containing 6 sub-parameters) and no parameter semantics in the description, it fails to compensate for the schema's coverage gap. The agent must rely entirely on the schema's field-level descriptions without any high-level guidance from the tool description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List knowledge articles' clearly states the verb ('List') and resource ('knowledge articles'), providing a basic understanding of the tool's function. However, it lacks specificity about scope or differentiation from sibling tools like 'get_article' or 'list_knowledge_bases', making it somewhat vague. It avoids tautology by not merely restating the name, but doesn't fully distinguish itself from related operations.
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. With sibling tools like 'get_article' (for retrieving a specific article) and 'list_knowledge_bases' (for listing knowledge bases rather than articles), there's clear potential for confusion, but the description offers no explicit or implied context for selection. This absence of usage guidance leaves the agent without direction on appropriate tool choice.
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 carries full burden for behavioral disclosure. The description only states the basic action without mentioning pagination behavior, rate limits, authentication requirements, or what the output looks like. For a list operation with no annotation coverage, this leaves significant gaps in understanding how the tool behaves.
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 extremely concise at just 4 words, with no wasted language. It's front-loaded with the core action and resource, making it easy to parse quickly. Every word earns its place in conveying the essential 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?
Given the complexity (1 parameter that's a nested object with 4 sub-parameters), no annotations, and no output schema, the description is insufficiently complete. It doesn't address parameter usage, output format, pagination behavior, or differentiation from similar tools, leaving too many open questions for effective tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides zero information about parameters. With schema description coverage at 0% and 1 required parameter (a nested object with 4 sub-parameters), the description fails to compensate for the complete lack of parameter documentation in the schema. An agent would have no semantic understanding of what inputs are needed or how they affect the listing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List service catalog categories' clearly states the verb 'List' and resource 'service catalog categories', which is specific enough to understand the basic function. However, it doesn't distinguish this tool from similar sibling tools like 'list_categories' or 'list_catalog_items', leaving ambiguity about scope and differentiation.
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. With sibling tools like 'list_categories' and 'list_catalog_items' available, there's no indication of whether this tool is for a specific subset, different filtering capabilities, or other contextual differences that would help an agent choose correctly.
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. 'List service catalog items' implies a read-only operation but doesn't specify whether this requires authentication, what format the results come in, whether there are rate limits, or if the listing includes all items or only accessible ones. For a tool with zero annotation coverage, this minimal description leaves critical behavioral aspects undocumented.
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 maximally concise at just four words: 'List service catalog items.' It's front-loaded with the core action and resource, with no unnecessary words or redundant information. While it may be too brief for completeness, as a standalone statement it's efficiently structured.
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?
Given the complexity (5 sub-parameters in a nested structure), no annotations, no output schema, and 0% schema description coverage, the description is inadequate. It doesn't explain what 'service catalog items' are in this context, how results are returned, what filtering options exist, or any behavioral characteristics. For a tool with this level of complexity and no supporting structured data, the description should provide much more context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides zero information about parameters, while the schema description coverage is 0% (the schema has descriptions, but coverage calculation shows 0%). With 1 parameter (a nested object containing 5 sub-parameters) and no parameter information in the description, there's a significant gap. The description doesn't compensate for the schema's lack of coverage, leaving agents with insufficient understanding of how to use the tool effectively.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List service catalog items' clearly states the verb ('List') and resource ('service catalog items'), providing a basic understanding of the tool's function. However, it doesn't distinguish this tool from its sibling 'list_catalog_categories' or 'get_catalog_item', leaving ambiguity about scope and specificity. The purpose is clear but lacks differentiation from related tools.
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 like 'get_catalog_item' (for single items) or 'list_catalog_categories' (for categories). There's no mention of prerequisites, typical use cases, or contextual factors that would help an agent choose this tool appropriately among the many sibling tools available.
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 states the action ('List') but doesn't describe traits like whether it's read-only, paginated, rate-limited, or what permissions are required. For a list operation with multiple parameters, this lack of behavioral 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, efficient sentence with no wasted words. It's front-loaded with the core action and resource, making it easy to parse quickly. This minimal structure is appropriate for such a brief statement.
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?
Given the complexity (8 parameters with 0% schema coverage, no annotations, no output schema), the description is incomplete. It doesn't explain what the tool returns, how filtering works, or any behavioral aspects. For a list tool with rich filtering options, this minimal description is inadequate to guide proper use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, meaning none of the 8 parameters (limit, offset, state, type, category, assignment_group, timeframe, query) are documented in the schema. The description adds no parameter information beyond the tool name, failing to compensate for this coverage gap. This leaves all parameters semantically undefined.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List change requests from ServiceNow' clearly states the verb ('List') and resource ('change requests from ServiceNow'), making the basic purpose understandable. However, it lacks specificity about scope (e.g., all change requests or filtered ones) and doesn't distinguish it from sibling tools like 'get_change_request_details' or 'list_changesets', leaving room for ambiguity.
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. For example, it doesn't clarify if this should be used for browsing change requests versus 'get_change_request_details' for detailed views, or how it relates to 'list_changesets'. The absence of context or exclusions leaves the agent without usage direction.
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 full burden but discloses almost nothing beyond the basic action. It doesn't mention whether this is a read-only operation, if it requires authentication, how results are returned (e.g., paginated), rate limits, or error conditions. For a listing tool with zero annotation coverage, this is a significant gap in 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, efficient sentence with zero wasted words. It's appropriately sized for a simple listing tool and front-loads the core action, though this conciseness comes at the cost of detail.
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?
Given the tool's complexity (7 parameters with no schema descriptions, no output schema, no annotations), the description is incomplete. It doesn't explain what a changeset is, how results are structured, filtering options, or typical use cases. For a parameter-rich tool in a ServiceNow context, this leaves the agent with insufficient information to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions no parameters, while the input schema has 7 parameters (limit, offset, state, application, developer, timeframe, query) with 0% schema description coverage. This leaves all parameters undocumented in both schema and description, failing to compensate for the coverage gap. The agent must infer parameter usage from names alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List changesets from ServiceNow' states the basic action (list) and resource (changesets), but is vague about scope and lacks differentiation from siblings like 'list_change_requests' or 'get_changeset_details'. It doesn't specify whether this lists all changesets or filtered ones, making it minimally adequate but with clear gaps.
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 'get_changeset_details' (for specific changesets) or 'list_change_requests' (for related entities). The description implies a listing function but offers no context on prerequisites, filtering capabilities, or typical use cases.
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 carries full burden for behavioral disclosure. The description only states what the tool does at a high level without mentioning pagination behavior, rate limits, authentication requirements, response format, or whether this is a read-only operation. For a tool with 4 parameters and no annotations, this is insufficient.
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 extremely concise at just 5 words. It's front-loaded with the core purpose and wastes no words. While it may be too brief for completeness, as a standalone statement it's efficiently structured.
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 tool with 4 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what a 'knowledge base' is in ServiceNow context, doesn't describe parameters or their effects, and provides no information about the return format. Given the complexity implied by the parameter set, this description leaves too many questions unanswered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning none of the 4 parameters have descriptions in the schema. The tool description provides no information about parameters whatsoever - it doesn't mention limit, offset, active filtering, or query capabilities. With 4 undocumented parameters and no compensation in the description, this is a critical gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List knowledge bases from ServiceNow' clearly states the verb ('List') and resource ('knowledge bases'), but it's vague about scope and doesn't differentiate from sibling tools like 'list_articles' or 'list_categories'. It doesn't specify whether this lists all knowledge bases or has specific filtering capabilities beyond what parameters imply.
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. With sibling tools like 'create_knowledge_base', 'get_article', and 'list_articles', there's no indication of when listing knowledge bases is appropriate versus listing articles or other resources. The description offers no context about prerequisites or typical use cases.
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 but offers only the basic action ('List'). It doesn't describe whether this is a read-only operation, if it requires authentication, how results are returned (e.g., paginated format), potential rate limits, or error conditions. For a tool with parameters and no annotations, this is a significant gap in transparency.
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, efficient sentence with zero wasted words. It is appropriately sized for a basic tool and front-loaded with the core action, though this conciseness comes at the cost of detail. Every word earns its place by stating the essential 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?
Given the complexity (5 sub-parameters, no output schema, no annotations), the description is incomplete. It lacks details on behavior, parameter usage, return values, and differentiation from siblings. For a list tool with filtering options, this minimal description doesn't provide enough context for effective agent use, especially compared to more documented siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions no parameters, while the input schema has 1 parameter (a nested object with 5 sub-parameters) and 0% schema description coverage (the schema's descriptions are generic). This leaves all parameter details undocumented in both the schema and description, failing to compensate for the low coverage. The agent must infer usage from parameter names alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List script includes from ServiceNow' states the verb ('List') and resource ('script includes') with the platform context ('from ServiceNow'), which provides a basic purpose. However, it doesn't distinguish this tool from other list tools like list_articles or list_users, nor does it specify what 'list' entails (e.g., filtered retrieval vs. full dump). This makes it vague compared to more specific sibling tools.
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. There are no explicit when/when-not instructions, no mention of prerequisites (e.g., permissions), and no reference to sibling tools like get_script_include for single-item retrieval or create_script_include for creation. This leaves the agent with minimal context for 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states 'List users' which implies a read-only operation, but doesn't clarify permissions needed, pagination behavior (implied by parameters but not described), rate limits, or what the output looks like (no output schema). This is a significant gap for a tool with multiple parameters and no structured safety hints.
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 extremely concise with just four words ('List users in ServiceNow'), making it front-loaded and waste-free. It efficiently communicates the core purpose without unnecessary elaboration, though this brevity contributes to gaps in other dimensions.
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?
Given the tool's complexity (5 parameters, no annotations, no output schema), the description is incomplete. It doesn't explain parameter usage, output format, behavioral traits like pagination or filtering, or how it differs from sibling tools. For a list operation with multiple filters, more context is needed to guide effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides no information about parameters, while the schema description coverage is 0% (the schema has descriptions, but coverage calculation is given as 0%). With 5 parameters documented only in the schema and no additional context in the description, the agent lacks semantic understanding beyond raw schema definitions. The description fails to compensate for the low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List users in ServiceNow' clearly states the verb ('List') and resource ('users in ServiceNow'), making the purpose understandable. However, it lacks specificity about what kind of listing this provides (e.g., filtered vs. all users) and doesn't distinguish it from sibling tools like 'get_user' or 'create_user' beyond the basic action.
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 doesn't mention any prerequisites, filtering capabilities, or comparison to other user-related tools like 'get_user' (for single user details) or 'create_user' (for creating users), 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 provided, the description carries the full burden of behavioral disclosure but offers minimal information. It doesn't state whether this is a read-only operation, what authentication is required, whether there are rate limits, what happens on failure, or what the return format looks like. 'List' implies a read operation, but the description lacks crucial behavioral context for a tool with 5 parameters.
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 extremely concise at just 4 words, with zero wasted language. It's front-loaded with the core action and resource. While it's under-specified, it's not verbose or poorly structured—it simply lacks necessary detail.
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?
Given the complexity (5 parameters in a nested structure, no annotations, no output schema), the description is incomplete. It doesn't explain what 'listing workflows' entails, what information is returned, how filtering works, or any behavioral constraints. For a tool with multiple filtering parameters and no output schema, this leaves significant gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides zero information about parameters. With 0% schema description coverage (the schema has no descriptions at the top level, only within nested definitions), the description fails to compensate by explaining what parameters are available, their purposes, or how they affect the listing. The agent must rely entirely on the nested schema definitions without any high-level guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List workflows from ServiceNow' clearly states the verb ('List') and resource ('workflows'), but it's vague about scope and format. It doesn't specify whether this lists all workflows, active workflows, or workflows with certain characteristics, nor does it mention the return format. While it distinguishes from obvious non-list siblings like 'create_workflow', it doesn't differentiate from similar list tools like 'list_workflow_versions'.
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 doesn't mention when to choose 'list_workflows' over 'list_workflow_versions' or 'get_workflow_details', nor does it specify prerequisites, required permissions, or typical use cases. The agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden but fails to disclose behavioral traits. It doesn't indicate if this is a read-only operation, what permissions are required, how results are structured, or any rate limits. For a list operation with zero annotation coverage, this is inadequate.
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, efficient sentence with zero wasted words. It's appropriately sized for a simple tool name and is front-loaded with the core action, though it lacks detail.
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?
Given no annotations, no output schema, and low schema coverage, the description is incomplete. It doesn't cover behavioral aspects, parameter meanings, or return values, making it insufficient for an agent to use the tool effectively in a complex ServiceNow context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/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 but adds no parameter information. It doesn't explain the 'workflow_id' parameter, the purpose of 'limit' and 'offset' for pagination, or any constraints. With 1 required parameter and 2 optional ones undocumented, this is a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List workflow versions from ServiceNow' clearly states the action (list) and resource (workflow versions), but it's vague about scope and doesn't distinguish from sibling tools like 'list_workflows' or 'get_workflow_details'. It provides basic purpose but lacks specificity about what 'versions' entails.
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 this tool versus alternatives like 'list_workflows' or 'get_workflow_details'. The description doesn't mention prerequisites, context, or exclusions, leaving the agent with no usage direction beyond the basic purpose.
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 but only states the action without behavioral details. It doesn't disclose that this is a mutation operation, what permissions are needed, whether it's irreversible, or what happens upon success/failure. This leaves critical behavioral traits unspecified.
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, efficient sentence with no wasted words. It's appropriately front-loaded with the core action, though this brevity contributes to the lack of detail in other dimensions.
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, 0% schema description coverage, and no output schema, the description is incomplete. It doesn't explain what 'resolve' means in ServiceNow context, parameter purposes, expected outcomes, or error conditions, leaving significant gaps for agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no parameter information. It doesn't mention the required 'params' object or its nested fields (incident_id, resolution_code, resolution_notes), leaving parameters completely undocumented beyond the schema structure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action ('Resolve') and target ('an incident in ServiceNow'), which provides a basic understanding of purpose. However, it's vague about what 'resolve' entails operationally and doesn't differentiate from sibling tools like 'update_incident' or 'create_incident' that might handle incident states.
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. It doesn't mention prerequisites (e.g., incident must be in a specific state), exclusions, or how it differs from related tools like 'update_incident' for modifying incidents.
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 carries the full burden of behavioral disclosure. It states 'Update' which implies a mutation, but fails to describe any behavioral traits such as required permissions, whether changes are reversible, what happens to unspecified fields, or error conditions. This is a significant gap for a mutation tool with zero annotation coverage.
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, efficient sentence with zero wasted words. It is appropriately sized for a basic purpose statement, though this conciseness comes at the cost of missing important details that would enhance usability.
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?
Given the complexity (a mutation tool with 8 updatable fields), no annotations, no output schema, and low schema coverage, the description is incomplete. It fails to address key aspects like what the tool returns, error handling, or the impact of updates, making it inadequate for safe and effective use by an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides no information about parameters beyond the generic 'update' action. With 1 parameter (a nested object containing 8 fields) and 0% schema description coverage, the schema lacks titles or descriptions for the nested properties. The description does not compensate by explaining what 'item_id' refers to, what fields can be updated, or the semantics of null values, leaving parameters largely undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update a service catalog item' clearly states the verb ('Update') and resource ('service catalog item'), making the basic purpose understandable. However, it doesn't differentiate this tool from other update tools like 'update_catalog_category' or 'update_catalog_item_variable' among the siblings, leaving ambiguity about what specifically distinguishes this update operation.
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. With sibling tools like 'get_catalog_item' for reading and 'create_catalog_item_variable' for related operations, there's no indication of prerequisites, context (e.g., after retrieving an item), or exclusions, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It states 'Activate a workflow' but gives no information about what activation entails (e.g., changes workflow state, enables execution, requires specific permissions), potential side effects, error conditions, or response format. This is inadequate for a mutation tool with zero annotation coverage.
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 maximally concise - a single sentence with no wasted words. It's front-loaded with the core purpose and contains no unnecessary elaboration. While under-specified, it's structurally efficient for what it does convey.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 1 parameter, 0% schema coverage, no annotations, and no output schema, the description is completely inadequate. It doesn't explain what activation means, what parameter is needed, what permissions are required, what happens upon success/failure, or what the tool returns. The agent lacks essential context to use this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter documentation. The description mentions no parameters at all, failing to compensate for the schema gap. The single required parameter 'workflow_id' is completely undocumented in both schema and description, leaving the agent guessing about format, constraints, or examples.
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 the action ('Activate') and resource ('a workflow in ServiceNow'), making the purpose immediately understandable. It doesn't specifically differentiate from its sibling 'deactivate_workflow', but the verb 'activate' provides inherent contrast. The description avoids tautology by not just repeating the tool name.
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 doesn't mention prerequisites (e.g., workflow must exist, user permissions), nor does it contrast with similar tools like 'update_workflow' or 'create_workflow'. The agent must infer usage context from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but fails to disclose behavioral traits. It doesn't mention if deletion is permanent, requires specific permissions, affects related workflow elements, or has side effects. This is inadequate for a destructive 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 a single, clear sentence with zero wasted words, making it easy to parse. It's front-loaded with the core action, though this brevity comes at the cost of completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with no annotations, no output schema, and minimal parameter guidance, the description is severely incomplete. It fails to address critical aspects like safety, return values, or error handling, making it inadequate for reliable use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no meaning beyond the input schema, which has 0% description coverage. It doesn't explain what 'activity_id' represents, its format (e.g., sys_id), or how to obtain it, leaving the single required parameter poorly understood.
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 the action ('Delete') and target ('an activity from a workflow'), which is specific and unambiguous. It distinguishes from siblings like 'add_workflow_activity' or 'reorder_workflow_activities' by focusing on removal, though it doesn't explicitly contrast with them.
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 when deletion is appropriate compared to deactivation or updating. It lacks context about prerequisites, permissions, or consequences, leaving the agent without usage direction.
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 full burden but offers minimal behavioral insight. It states it's a creation operation but doesn't disclose permissions needed, whether it's idempotent, what happens on duplicate titles, or what the response contains. For a mutation tool with zero annotation coverage, this leaves critical behavioral questions unanswered.
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, efficient sentence that gets straight to the point with zero wasted words. It's appropriately sized for a basic tool description and is perfectly front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with 5 parameters, 0% schema description coverage, no annotations, and no output schema, the description is completely inadequate. It doesn't explain parameters, behavioral expectations, success/failure conditions, or return values, leaving the agent with insufficient information to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions no parameters at all, while the input schema shows 5 parameters (title, description, knowledge_base, parent_category, active) with 0% schema description coverage. This leaves all parameter meanings undocumented, creating significant ambiguity about what's required for successful category creation.
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 the action ('Create') and resource ('a new category in a knowledge base'), making the purpose immediately understandable. It doesn't distinguish from sibling tools like 'create_catalog_category' or 'list_categories', but the verb+resource combination is specific enough for basic understanding.
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 doesn't mention prerequisites like needing an existing knowledge base, nor does it differentiate from similar tools like 'create_catalog_category' or explain when to use 'create_category' versus 'list_categories' for viewing existing ones.
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 states 'Get a specific service catalog item,' implying a read-only operation, but doesn't clarify aspects like authentication requirements, rate limits, error handling, or what 'Get' returns (e.g., full details vs. summary). This is a significant gap for a tool with zero annotation coverage.
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, efficient sentence with no wasted words. It's front-loaded and directly states the tool's purpose, making it easy to parse quickly, though this brevity contributes to gaps in other dimensions.
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?
Given the complexity (a retrieval tool with no output schema and 0% schema description coverage), the description is inadequate. It lacks details on return values, error conditions, and behavioral traits, leaving the agent with insufficient information to use the tool effectively. The conciseness comes at the cost of completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/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 compensate for undocumented parameters. It mentions 'specific service catalog item,' hinting at an identifier parameter, but doesn't explicitly name or explain the 'item_id' parameter from the schema. This adds minimal value beyond the schema, failing to fully address the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get a specific service catalog item' clearly states the verb ('Get') and resource ('service catalog item'), making the purpose understandable. However, it lacks specificity about what 'Get' entails (e.g., retrieve details, metadata) and doesn't distinguish it from sibling tools like 'list_catalog_items' or 'get_article', leaving room for ambiguity.
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 doesn't mention prerequisites (e.g., needing an item ID), exclusions, or comparisons to siblings like 'list_catalog_items' for browsing or 'get_article' for similar retrieval operations, leaving the agent to infer usage 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?
No annotations are provided, so the description carries full burden. It states 'Get' which implies a read operation, but doesn't disclose behavioral traits like whether this requires specific permissions, what format the recommendations come in, if there are rate limits, or if it's a computationally expensive operation. For a tool with zero annotation coverage, this is inadequate.
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, efficient sentence with no wasted words. It's appropriately sized for what it communicates and front-loads the core purpose immediately.
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?
Given zero annotation coverage, 0% schema description coverage, no output schema, and one parameter with nested structure, the description is incomplete. It doesn't explain what optimization recommendations are, what they look like, how parameters affect them, or behavioral considerations. For a tool that presumably provides actionable insights, this leaves significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/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. The description mentions no parameters at all, while the schema shows one required parameter 'params' with nested properties 'recommendation_types' and 'category_id'. The description provides zero information about what these parameters mean or how they affect the recommendations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get optimization recommendations for the service catalog' clearly states the action (get) and target (optimization recommendations for service catalog), but it's somewhat vague about what 'optimization recommendations' entail. It doesn't distinguish from siblings like 'list_catalog_items' or 'get_catalog_item' which might provide related data, though the focus on 'recommendations' provides some differentiation.
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 doesn't mention prerequisites, context, or what problem this tool solves compared to other catalog-related tools like 'list_catalog_items' or 'get_catalog_item'. The agent must infer usage from the tool 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?
With no annotations provided, the description carries full burden but only states the action ('Get') without disclosing behavioral traits. It doesn't mention whether this is a read-only operation, what permissions are required, how errors are handled, or the format of returned data. This leaves significant gaps in understanding the tool's behavior beyond the basic action.
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, straightforward sentence with no wasted words. It's front-loaded with the core action and resource, making it easy to parse quickly. Every part of the sentence contributes directly to stating the tool's purpose without unnecessary elaboration.
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?
Given the tool's complexity (1 parameter with nested properties), lack of annotations, no output schema, and low schema coverage, the description is incomplete. It doesn't address key aspects like parameter usage, return values, error conditions, or differentiation from siblings, making it inadequate for the agent to fully understand how to invoke and interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides no parameter information, while the input schema has 1 parameter (a nested object with three properties) and 0% schema description coverage. Since the schema lacks descriptions for the nested properties (user_id, user_name, email), the description fails to compensate by explaining what these parameters mean or how they're used, leaving semantics unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get a specific user in ServiceNow' clearly states the verb ('Get') and resource ('user'), but it's vague about what 'specific' means compared to sibling tools like 'list_users'. It doesn't distinguish whether this retrieves by ID, name, or other criteria, leaving ambiguity about its exact scope versus the list operation.
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 'list_users'. The description implies it's for retrieving a single user, but it doesn't specify prerequisites (e.g., needing a user identifier) or contrast it with other user-related tools, leaving the agent to infer usage context without explicit direction.
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 carries the full burden of behavioral disclosure. It states 'Get activities' but does not specify if this is a read-only operation, what permissions are required, how results are returned (e.g., pagination, format), or potential side effects. This leaves significant gaps for an agent to understand the tool's 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, clear sentence with no wasted words, making it front-loaded and easy to parse. It efficiently conveys the core action without unnecessary details, though this conciseness comes at the cost of completeness.
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?
Given the complexity of workflow systems, no annotations, no output schema, and low schema coverage, the description is insufficient. It lacks details on return values, error conditions, or operational context, making it inadequate for an agent to use the tool effectively in a broader environment.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions 'a specific workflow' but does not elaborate on parameters. With 0% schema description coverage and one required parameter ('workflow_id'), the description fails to add meaning beyond the schema. It does not explain what 'activities' entail or how the optional 'version' parameter affects results, compensating poorly for the low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get activities for a specific workflow' clearly states the verb ('Get') and resource ('activities for a specific workflow'), making the purpose understandable. However, it does not differentiate from sibling tools like 'get_workflow_details' or 'list_workflows', which might retrieve related but different information, leaving some ambiguity in scope.
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. With siblings like 'get_workflow_details' and 'list_workflow_versions', it's unclear if this tool is for listing all activities, filtering by status, or retrieving metadata, offering no context for 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool is for getting information, implying a read-only operation, but doesn't specify authentication needs, rate limits, error handling, or what 'detailed information' includes (e.g., structure, metadata). For a tool with zero annotation coverage, this leaves significant gaps in understanding its 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, efficient sentence with no wasted words. It's front-loaded with the core purpose ('Get detailed information'), making it easy to scan. Every word contributes to the tool's intent, achieving optimal conciseness.
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?
Given the complexity of a workflow tool with no annotations, no output schema, and low schema coverage, the description is incomplete. It doesn't cover what information is returned, error cases, or how it differs from sibling tools. For a tool that likely returns structured data, more context is needed to be fully helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions 'a specific workflow' but doesn't explain parameters. With 0% schema description coverage and 1 parameter (workflow_id), the schema only provides basic titles and types. The description fails to add meaning, such as what constitutes a valid workflow ID or how to obtain it, leaving the parameter semantics unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool's purpose as 'Get detailed information about a specific workflow', which is clear but vague. It specifies the verb ('Get') and resource ('workflow'), but doesn't distinguish it from siblings like 'get_workflow_activities' or 'list_workflows'. The description lacks specificity about what 'detailed information' entails.
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 doesn't mention siblings like 'list_workflows' (for listing workflows) or 'get_workflow_activities' (for workflow activities), nor does it specify prerequisites such as needing a workflow ID. Usage context is implied but not explicit.
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 carries the full burden of behavioral disclosure. It states this is an update operation, implying mutation, but doesn't cover critical aspects like required permissions, whether changes are reversible, error handling, or side effects. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
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, straightforward sentence with no wasted words. It's front-loaded with the core action and resource, making it easy to parse quickly. Every word earns its place by conveying essential information about the tool's function.
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?
Given the complexity of updating a workflow (a mutation operation with multiple parameters), lack of annotations, no output schema, and 0% schema description coverage, the description is inadequate. It doesn't explain what the tool returns, error conditions, or behavioral nuances, leaving too many gaps for effective agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides no parameter information beyond implying a workflow needs updating. With 0% schema description coverage and 1 parameter (a nested object with 6 sub-parameters), the description fails to compensate for the lack of schema documentation. It doesn't mention required fields like 'workflow_id' or optional ones like 'name' or 'active', leaving parameters largely unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update an existing workflow in ServiceNow' clearly states the verb ('Update') and resource ('workflow in ServiceNow'), but it's generic and doesn't distinguish this tool from its sibling 'update_workflow_activity'. It specifies the target system (ServiceNow), which adds some specificity, but lacks details about what aspects of a workflow can be updated.
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 doesn't mention prerequisites (e.g., needing an existing workflow ID), compare it to 'create_workflow' or 'deactivate_workflow', or indicate typical use cases. This leaves 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 provided, the description carries full burden for behavioral disclosure. 'Add a file to a changeset' implies a write/mutation operation, but the description doesn't address permissions needed, whether this is reversible, what happens if the file already exists, rate limits, or what the response looks like. This leaves significant gaps 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, efficient sentence with no wasted words. It's appropriately sized for what it communicates, though it's under-specified rather than truly concise.
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 3 parameters, 0% schema description coverage, no annotations, and no output schema, the description is inadequate. It states the basic purpose but fails to provide usage context, parameter guidance, behavioral details, or output expectations, leaving the agent with insufficient information to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides zero information about parameters. With schema description coverage at 0% (the schema has no parameter descriptions beyond titles), the description doesn't compensate at all. It doesn't explain what 'changeset_id', 'file_path', or 'file_content' mean or require, leaving all three parameters undocumented.
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 the action ('Add a file') and target ('to a changeset in ServiceNow'), providing a specific verb+resource combination. However, it doesn't differentiate from sibling tools like 'commit_changeset' or 'publish_changeset' that also operate on changesets, nor does it explain what a changeset is in this 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 guidance is provided about when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., whether a changeset must exist first), sequencing (e.g., use before committing), or alternatives among the many sibling tools that also manipulate changesets.
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. While 'Add' implies a write/mutation operation, the description doesn't specify required permissions, whether this action is reversible, potential side effects, or error conditions. It lacks critical behavioral context for a mutation tool in a complex system like ServiceNow.
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, efficient sentence that states the core purpose without unnecessary words. It's appropriately sized for a tool with a clear name and follows the principle of front-loading the most important information. Every word earns its place.
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, 0% schema description coverage, no output schema, and complex nested parameters, the description is inadequate. It doesn't explain what constitutes a successful addition, what data is returned, error handling, or system-specific constraints. The agent lacks sufficient context to use this tool effectively in the ServiceNow ecosystem.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides zero information about parameters, while the schema has 0% description coverage (only titles, no descriptions in the main schema). With 1 required parameter (a nested object with 5 properties), the agent receives no semantic guidance about what 'params' should contain, what 'workflow_version_id' refers to, or how 'activity_type' values like 'approval' differ in behavior.
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 the action ('Add a new activity') and target resource ('to a workflow in ServiceNow'), making the purpose immediately understandable. It distinguishes from siblings like 'create_workflow' or 'update_workflow_activity' by focusing specifically on activity addition rather than workflow creation or modification. However, it doesn't explicitly differentiate from 'reorder_workflow_activities' or 'delete_workflow_activity' in the same domain.
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 doesn't mention prerequisites (e.g., needing an existing workflow version), when not to use it, or how it differs from related tools like 'create_workflow' or 'update_workflow_activity'. The agent must infer usage context solely from the tool name and description.
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 carries full burden. It mentions 'Commit' which implies a write/mutation operation, but doesn't disclose behavioral traits like whether this is destructive, requires specific permissions, has side effects, or what happens post-commit. This is inadequate for a tool that likely alters system state.
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, efficient sentence with no wasted words. It's front-loaded with the core action and context, making it easy to parse quickly, though this brevity contributes to other deficiencies.
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?
Given no annotations, no output schema, and 0% schema description coverage for a mutation tool, the description is incomplete. It lacks essential context like what 'commit' entails, expected outcomes, error conditions, or how it differs from similar tools, making it insufficient for reliable agent 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?
Schema description coverage is 0%, so the description must compensate. It adds no parameter information beyond what's implied by the tool name. The schema defines 'changeset_id' and optional 'commit_message', but the description doesn't explain their roles, formats, or constraints, leaving gaps in understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action ('Commit') and target ('a changeset in ServiceNow'), which provides a basic purpose. However, it's vague about what 'commit' means operationally and doesn't distinguish from sibling tools like 'publish_changeset' or 'update_changeset', leaving ambiguity about when to use each.
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. With siblings like 'publish_changeset', 'update_changeset', and 'create_changeset', the description fails to specify prerequisites, sequencing, or exclusions, leaving the agent to guess based on tool names 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?
With no annotations provided, the description carries full burden for behavioral disclosure. While 'Create' implies a write operation, it doesn't mention permissions required, whether creation is immediate or requires approval, what happens on failure, or any rate limits. For a mutation tool with zero annotation coverage, this leaves significant gaps in understanding how the tool behaves.
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, efficient sentence that gets straight to the point with zero wasted words. It's appropriately sized for a basic tool description and front-loads the essential information.
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 creation tool with 7 parameters, 0% schema description coverage, no annotations, and no output schema, the description is severely inadequate. It doesn't explain what parameters are needed, what the tool returns, or any behavioral considerations. The context demands much more comprehensive documentation than what's provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, meaning none of the 7 parameters (title, text, short_description, knowledge_base, category, keywords, article_type) have descriptions in the schema. The tool description provides absolutely no information about these parameters, failing to compensate for the complete lack of schema documentation.
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 'Create a new knowledge article' clearly states the verb ('Create') and resource ('knowledge article'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'create_category' or 'create_knowledge_base' that also create different resources, so it doesn't reach the highest score.
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. There are sibling tools like 'create_knowledge_base' (for creating the container) and 'update_article' (for modifying existing articles), but the description offers no comparison or context for choosing between them.
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 full burden for behavioral disclosure. While 'Create' implies a write/mutation operation, the description doesn't address critical aspects like required permissions, whether the operation is idempotent, what happens on failure, or what the response contains. It provides minimal behavioral context beyond the basic action.
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, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded with the essential information, making it easy to parse quickly.
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 creation/mutation tool with no annotations, no output schema, and 10 parameters with poor schema documentation, the description is inadequate. It doesn't compensate for the missing structured information about behavior, parameters, or return values, leaving significant gaps for an agent trying to use this tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides zero information about parameters, while the schema has 0% description coverage (the schema descriptions are generic like 'Short description of the change request'). With 10 parameters in the nested object and no meaningful guidance in either schema or description, this represents a significant documentation gap.
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 the action ('Create a new change request') and target resource ('in ServiceNow'), providing a specific verb+resource combination. However, it doesn't distinguish this tool from similar sibling tools like 'create_incident' or 'create_article' beyond the resource name, which prevents a perfect score.
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. With sibling tools like 'update_change_request' and 'list_change_requests' available, there's no indication of when creation is appropriate versus modification or retrieval, nor any mention of prerequisites or constraints.
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 full burden for behavioral disclosure. While 'Create' implies a write operation, it doesn't mention required permissions, whether the operation is idempotent, what happens on failure, or any rate limits. This leaves significant behavioral gaps 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, efficient sentence that states the core purpose without unnecessary words. It's appropriately sized for a basic tool description and front-loads the essential information.
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, no output schema, and 8 undocumented parameters, the description is severely incomplete. It provides only the basic action without addressing behavioral aspects, parameter meanings, or expected outcomes, leaving the agent with insufficient context for proper tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides zero information about parameters, while the schema has 0% description coverage (the single 'params' object lacks meaningful description). With 8 nested parameters completely undocumented in both schema and description, this represents a critical gap in parameter understanding.
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 the action ('Create') and resource ('new group in ServiceNow'), providing a specific verb+resource combination. However, it doesn't differentiate from sibling tools like 'update_group' or 'list_groups' beyond the basic action, which prevents a perfect score.
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 like 'update_group' or 'list_groups'. There's no mention of prerequisites, constraints, or typical use cases, leaving the agent with minimal contextual direction.
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 carries the full burden of behavioral disclosure. While 'Create' implies a write operation, the description doesn't address critical aspects like required permissions, whether the operation is idempotent, what happens on failure, or the format of the response. For a mutation tool with zero annotation coverage, this leaves significant gaps in understanding its 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, efficient sentence with zero wasted words. It's front-loaded with the core action ('Create a new incident') and specifies the context ('in ServiceNow') clearly. Every word earns its place, making it easy to parse quickly.
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?
Given the complexity (a write operation with multiple nested parameters), lack of annotations, 0% schema description coverage, and no output schema, the description is incomplete. It doesn't explain parameter requirements, behavioral traits, or expected outcomes, leaving the agent with insufficient information to use the tool effectively beyond its basic purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, meaning none of the 1 parameter (which is a nested object with multiple sub-properties) has descriptions in the schema. The description provides no information about parameters, not even mentioning that 'short_description' is required or what other fields like 'priority' or 'category' mean. This fails to compensate for the schema's lack of documentation.
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 the verb ('Create') and resource ('a new incident in ServiceNow'), making the purpose immediately understandable. It distinguishes from siblings like 'update_incident' and 'resolve_incident' by specifying creation rather than modification or resolution. However, it doesn't explicitly differentiate from other creation tools like 'create_change_request' or 'create_article' beyond the resource type.
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 doesn't mention prerequisites (e.g., required permissions), when not to use it (e.g., for updating existing incidents), or clarify its role relative to sibling tools like 'update_incident' or 'resolve_incident'. The agent must infer usage from the name and context 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 carries the full burden of behavioral disclosure. 'Create a new knowledge base' implies a write/mutation operation, but the description doesn't mention required permissions, whether this is an idempotent operation, what happens on failure, or what the response contains. For a creation tool with zero annotation coverage, this is insufficient.
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, efficient sentence with no wasted words. It's front-loaded with the core action and resource, making it immediately understandable despite its brevity.
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 creation tool with 6 parameters, 0% schema description coverage, no annotations, and no output schema, the description is inadequate. It doesn't explain what parameters are needed, what the tool returns, or any behavioral aspects. The description should provide much more context given the complexity and lack of structured documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning none of the 6 parameters (title, description, owner, managers, publish_workflow, retire_workflow) are documented in the schema. The description provides zero information about any parameters, their purposes, or how they should be used, failing to compensate for the complete lack of schema documentation.
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 the action ('Create') and resource ('knowledge base in ServiceNow'), making the purpose immediately understandable. It doesn't differentiate from siblings like 'create_article' or 'create_category', but it's specific enough to identify the exact resource being created.
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. With siblings like 'list_knowledge_bases' and 'create_article' available, there's no indication of prerequisites, appropriate contexts, or when this tool is the right choice versus other creation tools.
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 states the tool creates a new script include, implying a write operation, but doesn't mention potential side effects, permissions required, error handling, or what happens on success (e.g., returns an ID or confirmation). This leaves significant gaps for an agent to understand the tool's 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, direct sentence with no wasted words, making it highly concise and front-loaded. It efficiently communicates the core purpose without unnecessary elaboration.
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?
Given the complexity of creating a script include with multiple parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what the tool returns, error conditions, or how parameters interact, leaving the agent with insufficient information to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, meaning none of the parameters (e.g., 'name', 'script', 'description') are documented in the schema. The description adds no information about these parameters, failing to compensate for the lack of schema documentation, which is critical for a tool with multiple input fields.
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 the action ('Create') and resource ('script include in ServiceNow'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'update_script_include' or 'delete_script_include' beyond the basic verb, missing explicit comparison.
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_script_include' or 'get_script_include'. The description lacks context about prerequisites, such as needing specific permissions or when creation is appropriate versus updating an existing script include.
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 carries the full burden of behavioral disclosure. While 'Create' implies a write operation, the description doesn't specify whether this requires admin permissions, what happens on duplicate usernames, if the user is immediately active, or the response format. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
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, efficient sentence with no wasted words. It's front-loaded with the core action and resource, making it easy to parse quickly. Every word earns its place in conveying the 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?
Given the complexity of creating a user (a mutation with 13 potential fields), no annotations, and no output schema, the description is incomplete. It doesn't address permissions, error conditions, return values, or how to handle optional vs. required fields, leaving critical gaps for the agent to operate effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions no parameters, while the input schema has 1 parameter (a nested object with 13 properties). With 0% schema description coverage, the schema itself provides all parameter details, but the description adds zero semantic context about what fields are needed or their purposes, failing to compensate for the coverage gap.
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 the verb ('Create') and resource ('new user in ServiceNow'), making the purpose unambiguous. However, it doesn't distinguish this tool from other user-related tools like 'update_user' or 'get_user' among the siblings, which would require explicit differentiation for a perfect score.
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 like 'update_user' or 'get_user', nor does it mention prerequisites such as required permissions or system context. It lacks any usage context, leaving the agent to infer when this operation is appropriate.
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. While 'Create' implies a write operation, the description doesn't mention required permissions, whether this operation is idempotent, potential side effects, error conditions, or what happens upon success (e.g., returns a workflow ID). For a creation tool with zero annotation coverage, this represents a significant gap in 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, efficient sentence that states the core purpose without unnecessary words. It's appropriately sized for a basic tool description and front-loads the essential information. Every word earns its place in conveying the fundamental action.
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 creation tool with 5 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what constitutes a valid workflow, what happens after creation, error handling, or authentication requirements. The description provides only the minimal action statement without the necessary context for effective tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides zero information about parameters beyond what's implied by 'workflow'. With 0% schema description coverage and 5 parameters (through the nested 'params' object), the description fails to compensate for the complete lack of parameter documentation in the schema. The agent must rely entirely on the schema's property names without any semantic guidance from the description.
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 the action ('Create') and resource ('a new workflow in ServiceNow'), providing specific verb+resource information. It distinguishes from siblings like 'update_workflow' or 'list_workflows' by specifying creation rather than modification or listing. However, it doesn't explicitly differentiate from other creation tools like 'create_change_request' or 'create_incident' beyond the workflow focus.
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. There are no indications of prerequisites, constraints, or comparisons with sibling tools like 'activate_workflow', 'deactivate_workflow', or 'update_workflow'. The agent must infer usage context solely from the tool name and description without explicit direction.
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 carries the full burden of behavioral disclosure. 'List' implies a read-only operation, but the description doesn't specify if it returns all categories or requires filtering, mention pagination behavior (implied by 'limit' and 'offset' in schema but not described), or detail error conditions. For a tool with 6 parameters and no annotation coverage, this is insufficient.
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, efficient sentence with zero wasted words. It's front-loaded with the core action ('List categories') and context ('in a knowledge base'), making it easy to parse. Every word earns its place, though this conciseness comes at the cost of detail in other dimensions.
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?
Given the complexity (6 parameters with 0% schema coverage, no annotations, no output schema), the description is incomplete. It doesn't explain what the tool returns (e.g., list of category objects), how filtering works, or behavioral aspects like pagination. For a list operation with multiple filters, this leaves significant gaps for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning parameter descriptions are missing in the schema. The tool description adds no information about parameters—it doesn't mention any filters like 'knowledge_base', 'parent_category', or 'query', or explain pagination with 'limit' and 'offset'. With 6 parameters entirely undocumented, this fails to compensate for the schema gap.
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 'List categories in a knowledge base' clearly states the verb ('List') and resource ('categories'), specifying the domain ('knowledge base'). It distinguishes from siblings like 'list_articles' or 'list_knowledge_bases' by focusing on categories. However, it doesn't explicitly differentiate from 'list_catalog_categories', which might be a similar but distinct resource, keeping it from a perfect score.
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 doesn't mention prerequisites (e.g., needing a knowledge base ID), exclusions, or comparisons to siblings like 'list_catalog_categories'. This lack of context leaves the agent to infer usage based on the tool 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?
With no annotations provided, the description carries full burden for behavioral disclosure. It states this is a list operation with filtering, but doesn't describe authentication requirements, rate limits, pagination behavior (though schema hints at it), error conditions, or what the output looks like. For a tool with 5 parameters and no output schema, this leaves significant gaps.
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, efficient sentence that states the core functionality upfront with no wasted words. It follows a clear 'verb + resource + qualifier' structure that's immediately scannable.
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 tool with 5 parameters, no annotations, no output schema, and 0% schema description coverage, the description is inadequate. It doesn't explain the return format, error handling, authentication needs, or provide meaningful parameter guidance. The description fails to compensate for the missing structured documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0% (the single parameter 'params' has no description in the schema), and the description only mentions 'optional filtering' without explaining what parameters are available or their semantics. With 5 actual parameters nested inside 'params', the description fails to compensate for the complete lack of schema documentation.
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 the verb ('list') and resource ('groups from ServiceNow') with scope ('with optional filtering'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'list_users' or 'list_workflows' beyond the resource type, which prevents a perfect score.
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 mentions 'optional filtering' which implies some usage context, but provides no explicit guidance on when to use this tool versus alternatives like 'get_group' (which doesn't exist in siblings) or how it relates to other list operations. No prerequisites, exclusions, or comparison to siblings are included.
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 carries the full burden of behavioral disclosure. It states the tool performs a 'move' operation, implying mutation, but lacks details on permissions required, whether the move is reversible, effects on item relationships, error handling (e.g., invalid IDs), or response format. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
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 front-loaded with the core action and resource, making it easy to parse quickly. Every part of the sentence contributes directly to understanding the tool's 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?
Given the tool's complexity (a mutation operation with two parameters), lack of annotations, and no output schema, the description is incomplete. It covers the basic purpose but misses critical context: parameter details, behavioral traits (e.g., side effects), error conditions, and return values. This leaves the agent with insufficient information to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions 'catalog items' and 'different category', which loosely relates to the parameters (item_ids and target_category_id), but adds no meaningful semantics beyond what the parameter names imply. With 0% schema description coverage and two required parameters, the description fails to explain what these IDs represent, format requirements, or constraints (e.g., array size limits). It does not compensate for the lack of schema documentation.
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 the action ('Move') and resource ('catalog items'), specifying the destination ('to a different category'). It distinguishes from siblings like 'update_catalog_item' or 'create_catalog_category' by focusing on relocation rather than modification or creation. However, it doesn't explicitly differentiate from potential similar tools like 'reorder_workflow_activities' in terms of scope.
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 doesn't mention prerequisites (e.g., needing existing items and categories), exclusions (e.g., cannot move to non-existent categories), or sibling tools that might be related (e.g., 'update_catalog_item' for other modifications). Usage is implied only by the action described.
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 carries the full burden of behavioral disclosure. It states the tool publishes a changeset but doesn't explain what this entails—such as whether it's a destructive operation, requires specific permissions, has side effects (e.g., affecting live systems), or includes rate limits. This leaves critical behavioral traits unspecified 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, direct sentence with no wasted words. It's appropriately sized for a simple tool name and efficiently conveys the core action and resource. The structure is front-loaded, making it easy to parse quickly.
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?
Given the complexity of a mutation tool with no annotations, 0% schema description coverage, and no output schema, the description is incomplete. It doesn't explain what 'publish' means behaviorally, what the parameters do, or what the tool returns. For a tool that likely modifies system state, this lack of context is a significant gap.
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 description adds no parameter information beyond what the input schema provides. Schema description coverage is 0%, meaning parameters are undocumented in both the schema and description. However, there is only 1 required parameter ('changeset_id'), which reduces complexity. The baseline score of 3 reflects minimal viability given the low parameter count, but no value is added over the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action ('publish') and resource ('a changeset in ServiceNow'), which provides a basic understanding of what the tool does. However, it doesn't specify what 'publish' means operationally (e.g., deploying changes, making them live) or differentiate it from similar tools like 'commit_changeset' or 'update_changeset' in the sibling list. This makes the purpose somewhat vague but not misleading.
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 offers no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., whether a changeset must be committed first), exclusions, or comparisons to sibling tools like 'commit_changeset' or 'update_changeset'. Without any usage context, the agent lacks direction on appropriate invocation scenarios.
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 carries the full burden. It states the tool submits for approval, implying a mutation that might trigger notifications or status changes, but doesn't disclose behavioral traits such as required permissions, whether it's idempotent, what happens on failure, or the expected response format. This leaves significant gaps for an agent to understand the tool's effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded and directly states the tool's purpose, making it easy to parse quickly. Every word earns its place, adhering to best practices for brevity in tool descriptions.
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?
Given the complexity of a submission tool with no annotations and no output schema, the description is incomplete. It doesn't address what the tool returns, error conditions, or side effects like notifications or status updates. For a mutation tool in a workflow context, more detail is needed to guide an agent effectively, making this inadequate for the task.
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 description adds no parameter semantics beyond the input schema. Schema description coverage is 0%, but the schema itself provides clear descriptions for 'change_id' and 'approval_comments'. Since the description doesn't explain parameters further, it doesn't compensate for the low coverage, but the schema is self-sufficient here, leading to a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Submit a change request for approval' clearly states the action (submit) and target (change request), but it's somewhat vague about what 'for approval' entails—does it initiate an approval workflow, send notifications, or change status? It distinguishes from obvious siblings like 'approve_change' and 'reject_change', but could be more specific about the exact operation.
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. For example, it doesn't clarify if this should be used after creating a change request with 'create_change_request', or if it's for a specific approval stage. The presence of sibling tools like 'approve_change' and 'reject_change' suggests a workflow, but the description offers no context on sequencing or prerequisites.
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 full burden for behavioral disclosure. 'Update' implies a mutation operation, but the description doesn't specify whether this requires special permissions, what happens to unspecified fields (partial vs. full updates), or potential side effects. It lacks critical context about the mutation's nature and consequences.
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, efficient sentence with zero wasted words. It's appropriately sized for a basic tool description and front-loads the core purpose immediately.
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, no output schema, and 7 nested parameter properties, the description is severely incomplete. It doesn't address behavioral aspects, parameter meanings, return values, or usage context. The agent would struggle to use this tool correctly without significant guessing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions no parameters at all, while the input schema has 1 parameter (a nested object with 7 properties). With 0% schema description coverage, the description fails to compensate by explaining what parameters are needed or their purposes, leaving the agent with no semantic understanding beyond raw schema structure.
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 the verb ('Update') and resource ('an existing service catalog category'), making the purpose unambiguous. However, it doesn't distinguish this tool from its sibling 'update_catalog_item' or other update tools, which would require more specific differentiation to earn a 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 provides no guidance on when to use this tool versus alternatives like 'create_catalog_category' or 'list_catalog_categories'. There's no mention of prerequisites, such as needing an existing category ID, or context about when updates are appropriate versus creating new categories.
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 full burden for behavioral disclosure. It states this is an update operation, implying mutation, but doesn't disclose any behavioral traits: no information about required permissions, whether changes are reversible, what happens to unspecified fields, error conditions, or response format. For a mutation tool with zero annotation coverage, this 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, efficient sentence that gets straight to the point with no wasted words. It's appropriately sized for a basic tool description and front-loads the essential information (update + resource).
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 11 parameters, no annotations, and no output schema, the description is severely incomplete. It doesn't explain what constitutes a valid change request ID, which fields are updatable, what the update operation returns, or any behavioral constraints. The agent would struggle to use this tool correctly without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides zero information about parameters. With schema description coverage at 0% (the schema has descriptions but they're not counted in coverage), the description fails to compensate by explaining what parameters are needed, what 'change_id' refers to, or which fields can be updated. This leaves all 11 parameters undocumented in the description context.
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 the action ('Update') and resource ('an existing change request in ServiceNow'), making the purpose immediately understandable. It distinguishes this from creation tools like 'create_change_request' by specifying 'existing', but doesn't explicitly differentiate from other update tools like 'update_article' or 'update_incident' beyond the resource type.
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 doesn't mention prerequisites (like needing a change request ID), when not to use it, or how it differs from similar update operations on other ServiceNow entities. The agent must infer usage from the tool 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states this is an update operation (implying mutation) but provides no information about permissions required, whether changes are reversible, rate limits, error conditions, or what happens to unspecified fields. For a mutation tool with zero annotation coverage, this leaves critical behavioral aspects undocumented.
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, efficient sentence that gets straight to the point with no wasted words. It's appropriately sized for a basic tool description and front-loads the essential information (action + resource).
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 5 parameters, 0% schema description coverage, no annotations, and no output schema, the description is inadequate. It doesn't explain what fields can be updated, what the update operation entails, what permissions are needed, or what the response contains. The agent would struggle to use this tool correctly without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides zero information about parameters beyond what's implied by 'update an existing changeset'. With 0% schema description coverage and 5 parameters (1 required, 4 optional), the schema definitions carry all the semantic weight. The description adds no value beyond what's already evident from the tool name and schema structure.
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 the action ('Update') and target resource ('an existing changeset in ServiceNow'), making the purpose immediately understandable. It distinguishes from sibling tools like 'create_changeset' by specifying 'existing', but doesn't fully differentiate from other update tools (e.g., 'update_change_request', 'update_workflow') beyond the resource type.
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 about when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., needing a changeset ID), when not to use it, or how it relates to sibling tools like 'update_change_request' or 'commit_changeset'. The agent must infer usage from the tool 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states this is an update operation (implying mutation), but doesn't mention required permissions, whether changes are reversible, error conditions, or what happens to unspecified fields. For a mutation tool with zero annotation coverage, this leaves significant gaps in understanding its 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, efficient sentence with no wasted words. It's appropriately sized for a basic tool description and front-loads the essential information (update operation on groups). Every word earns its place.
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?
Given this is a mutation tool with no annotations, no output schema, and 8 parameters with 0% schema description coverage, the description is inadequate. It should explain what fields can be updated, required permissions, typical use cases, and what the tool returns. The current description provides only the most basic context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides zero information about parameters, while the schema has 0% description coverage (the schema only has titles, not descriptions for parameters). With 8 parameters (group_id, name, description, manager, parent, type, email, active) completely undocumented in both the description and schema, this fails to add any meaningful semantic context beyond what's minimally present in 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 the action ('Update') and resource ('an existing group in ServiceNow'), providing a specific verb+resource combination. However, it doesn't differentiate this tool from its sibling 'create_group' or other update tools like 'update_user' or 'update_workflow', which would require explicit comparison to achieve a score of 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 provides no guidance on when to use this tool versus alternatives. There's no mention of prerequisites (like needing an existing group ID), when not to use it, or how it differs from similar tools such as 'create_group' or 'update_user'. The agent must 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states this is an update operation, implying mutation, but doesn't describe what happens when fields are updated (e.g., whether changes are logged, if certain fields trigger workflows, permission requirements, or what the response contains). For a mutation tool with 14 parameters and zero annotation coverage, this is a significant gap in 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, efficient sentence that gets straight to the point with no wasted words. It's appropriately sized for a basic tool description and front-loads the essential information (update + resource).
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 14 parameters, no annotations, and no output schema, the description is severely incomplete. It doesn't explain what fields can be updated, how updates affect the incident lifecycle, what permissions are required, or what the tool returns. The agent would struggle to use this tool effectively without significant external knowledge about ServiceNow incident management.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides zero information about parameters. With schema description coverage at 0% (the schema has descriptions but they're not counted in coverage), the description doesn't compensate at all. It doesn't mention the required 'incident_id' parameter or any of the 13 optional fields, leaving the agent completely dependent on the schema for parameter understanding.
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 the verb ('Update') and resource ('an existing incident in ServiceNow'), making the purpose immediately understandable. It distinguishes from sibling tools like 'create_incident' by specifying 'existing incident', but doesn't differentiate from other update tools like 'update_article' or 'update_change_request' beyond the resource type.
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 doesn't mention prerequisites (e.g., needing an existing incident ID), when not to use it, or how it differs from similar tools like 'resolve_incident' or 'update_change_request'. The agent must infer usage from the tool 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 carries the full burden of behavioral disclosure. While 'Update' implies a mutation operation, the description doesn't disclose any behavioral traits such as required permissions, whether changes are reversible, potential side effects, or what happens to unspecified fields. This is inadequate for a mutation tool with zero annotation coverage.
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, efficient sentence that states the core purpose without unnecessary words. It's appropriately sized and front-loaded, with every word earning its place by conveying the essential action and resource.
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?
Given the complexity (a mutation tool for updating script includes with 7 sub-parameters), no annotations, no output schema, and 0% schema description coverage, the description is insufficient. It doesn't explain what a script include is, what fields can be updated, the update behavior, or the expected response, leaving significant gaps for an AI agent to use this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides no information about parameters beyond what's implied by 'update an existing script include'. With 0% schema description coverage and 1 parameter (a nested object with 7 sub-parameters), the description fails to add any meaningful semantic context about what can be updated (e.g., script content, description, active status) or how to use the parameters.
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 the action ('Update') and resource ('an existing script include in ServiceNow'), making the purpose immediately understandable. However, it doesn't distinguish this tool from its sibling 'update_article', 'update_catalog_category', etc., which follow the same 'update [resource]' pattern, so it doesn't fully differentiate from siblings.
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 doesn't mention prerequisites (e.g., needing an existing script include ID), when not to use it (e.g., for creation vs. update), or refer to sibling tools like 'create_script_include' or 'delete_script_include' for related operations.
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 but offers minimal information. It implies a mutation operation ('Update') but doesn't cover critical aspects like required permissions, whether changes are reversible, error handling, or response format. This is inadequate for a mutation tool with zero annotation coverage.
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, efficient sentence with no wasted words. It's appropriately sized for a basic tool definition and front-loaded with the essential action and resource.
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?
Given the complexity (a mutation tool with 14 parameters), lack of annotations, 0% schema description coverage, and no output schema, the description is severely incomplete. It doesn't address behavioral traits, parameter meanings, or usage context, making it inadequate for effective tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, meaning none of the 14 parameters in the nested 'UpdateUserParams' object have descriptions in the schema. The tool description adds no parameter information beyond what's implied by the name 'update_user', failing to compensate for the complete lack of schema documentation.
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 the action ('Update') and resource ('an existing user in ServiceNow'), making the purpose immediately understandable. However, it doesn't differentiate this tool from sibling tools like 'update_group' or 'update_incident' beyond specifying the user resource, which prevents a perfect score.
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 doesn't mention prerequisites (e.g., needing a user_id), exclusions, or comparisons to sibling tools like 'create_user' or 'get_user', leaving the agent to infer usage 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 provided, the description carries full burden but offers minimal behavioral insight. It states it's an update operation, implying mutation, but doesn't disclose permissions required, whether changes are reversible, error conditions, or response format. This is inadequate for a mutation tool with zero annotation coverage.
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, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded and appropriately sized for its limited content, though this conciseness comes at the cost of detail.
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?
Given the complexity (mutation tool with nested parameters), lack of annotations, 0% schema coverage, and no output schema, the description is incomplete. It doesn't compensate for missing structured data, leaving critical gaps in understanding how to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no parameter information beyond what's inferred from the tool name. It doesn't explain the 'params' object, required 'activity_id', or optional fields like 'name' and 'description'. For a tool with 1 parameter (a nested object with multiple properties), this is a significant gap.
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 the verb ('Update') and resource ('an existing activity in a workflow'), making the purpose understandable. It distinguishes from siblings like 'add_workflow_activity' (create) and 'delete_workflow_activity' (remove). However, it doesn't specify what aspects can be updated (e.g., name, description), which prevents a perfect score.
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 doesn't mention prerequisites (e.g., needing an existing activity), exclusions, or comparisons to similar tools like 'update_workflow' or 'reorder_workflow_activities'. Usage is implied from the verb 'Update' but not explicitly 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?
With no annotations provided, the description carries full burden but only states the action without behavioral details. It doesn't disclose permission requirements, whether the operation is idempotent, error handling, or what happens if members already exist. 'Add' implies mutation but lacks safety or side-effect 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, efficient sentence with zero waste, clearly front-loaded with the core action. Every word contributes to understanding the tool's purpose without redundancy.
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, 0% schema coverage, and no output schema, the description is inadequate. It lacks details on permissions, error cases, return values, or how it differs from sibling tools like 'remove_group_members', leaving significant gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/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 but adds no parameter information. It doesn't explain what 'group_id' or 'members' represent beyond what the schema minimally provides (e.g., format examples, constraints). The single parameter 'params' is a nested object with two required fields, but the description offers no clarification.
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 the action ('Add members') and target resource ('to an existing group in ServiceNow'), providing a specific verb+resource combination. However, it doesn't differentiate from sibling 'remove_group_members' beyond the obvious verb difference, missing explicit comparison or scope details.
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_group' or 'create_group', nor does it mention prerequisites (e.g., group must exist). The description only states the basic function without context 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 carries full burden for behavioral disclosure. 'Create' implies a write/mutation operation, but the description doesn't mention permissions required, whether this is idempotent, what happens on duplicate titles, or what the response contains. For a creation tool with zero annotation coverage, this is insufficient.
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, efficient sentence that states the core function without unnecessary words. It's appropriately sized for a basic tool description, though its brevity contributes to gaps in other dimensions.
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 creation tool with 6 parameters (via nested object), 0% schema coverage, no annotations, and no output schema, the description is severely inadequate. It doesn't explain parameters, behavioral expectations, or return values, leaving the agent with insufficient information to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning none of the 6 nested parameters have descriptions in the schema. The tool description mentions no parameters at all, failing to compensate for this complete lack of schema documentation. The agent must guess what 'params' should contain.
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 the verb ('Create') and resource ('service catalog category'), making the purpose immediately understandable. It doesn't distinguish from sibling tools like 'create_category' or 'update_catalog_category', which would require explicit differentiation for a perfect score.
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 like 'create_category' or 'update_catalog_category', nor does it mention prerequisites, constraints, or typical use cases. It's a bare statement of function with zero contextual guidance.
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 carries the full burden. It states it 'gets' a script include, implying a read-only operation, but doesn't disclose behavioral traits such as authentication requirements, error handling (e.g., if the script include doesn't exist), rate limits, or what the return format looks like (e.g., JSON structure). This leaves significant gaps for an agent to invoke it correctly.
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, efficient sentence with no wasted words. It's front-loaded with the core purpose and appropriately sized for a simple retrieval tool, making it easy to parse quickly.
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?
Given the tool's moderate complexity (retrieval with one parameter), lack of annotations, and no output schema, the description is incomplete. It doesn't cover parameter details, return values, error conditions, or usage context, which are essential for an agent to operate this tool effectively in the broader ServiceNow ecosystem.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/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 mentions no parameters at all, while the input schema has one required parameter ('script_include_id'). The description fails to add any meaning beyond the schema, such as explaining what a script include ID is or providing examples (e.g., names vs. numeric IDs), leaving the parameter undocumented.
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 'Get a specific script include from ServiceNow' clearly states the verb ('Get') and resource ('script include'), and specifies it retrieves a 'specific' one rather than a list. However, it doesn't explicitly differentiate from sibling tools like 'list_script_includes' or 'get_article', which follow similar patterns but for different resources.
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 doesn't mention sibling tools like 'list_script_includes' for browsing or 'get_article' for similar retrieval operations on different resources, nor does it specify prerequisites or contextual constraints for usage.
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 mentions removal but doesn't specify whether this is reversible, what permissions are required, if there are side effects, or how failures are handled. For a mutation tool, this leaves significant gaps in understanding its 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, clear sentence with no wasted words, making it highly concise and front-loaded. It efficiently communicates the core purpose without unnecessary elaboration.
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, 0% schema coverage, and no output schema, the description is incomplete. It lacks details on behavior, parameters, and outcomes, leaving the agent with inadequate context to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning parameters are undocumented in the schema. The description doesn't add any parameter details beyond the tool name, failing to explain what 'group_id' or 'members' represent, their formats, or constraints, which is insufficient given the coverage gap.
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 the action ('Remove members') and target resource ('from an existing group in ServiceNow'), which is specific and unambiguous. However, it doesn't differentiate from sibling tools like 'add_group_members' or 'update_group', which would require explicit comparison.
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_group' or 'delete_group', nor does it mention prerequisites such as needing an existing group. The description only states what it does, not when it should be used.
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 states the action ('Add a comment') which implies a write/mutation operation, but doesn't disclose any behavioral traits: no information about permissions required, whether comments are editable/deletable, rate limits, side effects, or what happens on success/failure. For a mutation tool with zero annotation coverage, this leaves significant behavioral questions unanswered.
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, efficient sentence that states the core purpose without unnecessary words. It's appropriately sized for a straightforward tool and front-loads the essential information. Every word earns its place in conveying the tool's basic function.
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, no output schema, and 0% schema description coverage, the description is incomplete. It states what the tool does at a high level but lacks crucial context: no information about return values, error conditions, permissions, or behavioral details. Given the complexity of modifying data in a system like ServiceNow, more contextual information would be needed 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?
The description mentions 'an incident' and 'a comment', which aligns with the two required parameters in the schema (incident_id and comment). However, with 0% schema description coverage, the schema provides no parameter descriptions, and the description doesn't compensate by explaining parameter formats, constraints, or the optional 'is_work_note' parameter. The description adds minimal semantic context beyond parameter names.
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 the action ('Add a comment') and target resource ('to an incident in ServiceNow'), providing a specific verb+resource combination. It distinguishes this tool from other incident-related tools like 'create_incident', 'update_incident', and 'resolve_incident' by focusing specifically on comment addition. However, it doesn't explicitly differentiate from potential comment-related alternatives that might not exist in the sibling list.
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 doesn't mention prerequisites (e.g., incident must exist), when not to use it, or how it relates to other comment-adding mechanisms. While the sibling list shows no obvious comment-specific alternatives, there's no explicit comparison to general update tools or context about appropriate usage scenarios.
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 states the action ('Approve') but doesn't describe what happens upon approval (e.g., state transitions, notifications, permissions required, or side effects). For a mutation tool with zero annotation coverage, this is a significant gap in transparency about its behavior and implications.
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, straightforward sentence with no wasted words. It's front-loaded with the core action and resource, making it efficient and easy to parse. This is an example of appropriate conciseness for a simple tool.
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?
Given the tool's complexity (a mutation operation with no annotations, no output schema, and sibling tools like 'reject_change'), the description is inadequate. It lacks details on behavioral outcomes, usage context, and what distinguishes it from alternatives. For a tool that modifies system state, this minimal description leaves critical gaps for an AI agent to understand and invoke it 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?
The description doesn't mention any parameters, but the input schema has only one required parameter ('params' object with nested properties). With 0% schema description coverage, the description doesn't add parameter details, but the low parameter count (effectively 1) and clear schema structure mitigate this. The baseline is 4 since the tool has minimal parameters, though the description provides no additional semantic context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action ('Approve') and resource ('a change request'), making the basic purpose clear. However, it doesn't distinguish this tool from its sibling 'reject_change' or explain what approval entails beyond the verb. The purpose is understandable but lacks specificity about the approval process or its effects.
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 'reject_change' or 'submit_change_for_approval'. The description doesn't mention prerequisites (e.g., that the change must be in an approvable state) or context for when approval is appropriate. This leaves the agent with minimal usage direction.
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 full burden for behavioral disclosure. 'Deactivate' implies a state change operation, but the description doesn't specify whether this is reversible, what permissions are required, whether it affects running workflow instances, or what the expected outcome is. For a mutation tool with zero annotation coverage, this leaves significant behavioral questions unanswered.
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 extremely concise - a single sentence with no wasted words. It's front-loaded with the core action and resource. While this conciseness comes at the cost of completeness, the structure itself is efficient.
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, no output schema, and 0% schema description coverage, the description is inadequate. It doesn't explain what deactivation means in ServiceNow context, whether it's reversible, what permissions are needed, what happens to active instances, or what the tool returns. The presence of sibling tools like 'activate_workflow' and 'delete_workflow_activity' suggests this is part of a workflow management system that needs more contextual explanation.
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 0%, but the description provides no parameter information beyond what's implied by the tool name. The single parameter 'workflow_id' is documented in the schema but not explained in the description. Since there's only one parameter and the schema covers it, the baseline of 3 is appropriate, but the description adds no value beyond the obvious.
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 the action ('Deactivate') and resource ('a workflow in ServiceNow'), providing a specific verb+resource combination. However, it doesn't distinguish this tool from its sibling 'activate_workflow' beyond the obvious opposite action, missing an opportunity to clarify the relationship between these complementary operations.
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 about when to use this tool versus alternatives. While 'activate_workflow' is clearly the opposite operation, the description doesn't mention it or explain prerequisites like whether the workflow must be active first, what happens to running instances, or when deactivation might be appropriate versus deletion or modification.
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 carries full burden. It states 'Delete' which implies a destructive mutation, but fails to disclose critical behavioral traits like whether deletion is permanent, requires specific permissions, affects dependencies, or has confirmation steps. This leaves significant gaps in understanding the tool's 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, efficient sentence with zero wasted words, clearly front-loading the core action and resource. It's appropriately sized for the tool's complexity, making it easy to parse quickly.
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?
Given the tool's destructive nature, no annotations, no output schema, and minimal parameter guidance, the description is incomplete. It lacks details on consequences, error handling, or return values, which are crucial for safe and effective use in a ServiceNow context with many sibling tools.
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 0%, with one parameter ('script_include_id') documented only in the schema. The description adds no parameter semantics beyond what the schema provides, such as explaining what a script include ID is or format examples. Baseline is 3 due to adequate schema coverage, but no extra value is added.
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 the action ('Delete') and resource ('a script include in ServiceNow'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'delete_workflow_activity' or other deletion operations, which prevents a perfect score.
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 when to delete versus update a script include, or any prerequisites like permissions or dependencies. It lacks context for selection among siblings, leaving the agent with minimal usage direction.
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 full burden for behavioral disclosure. It states it 'gets' an article, implying a read-only operation, but doesn't mention permissions, error handling, or response format. For a tool with zero annotation coverage, this leaves significant gaps in understanding its 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, efficient sentence with no wasted words. It's front-loaded with the core action and resource, making it easy to parse quickly.
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?
Given no annotations, no output schema, and low schema description coverage, the description is incomplete. It doesn't address behavioral aspects like permissions or errors, nor does it explain the return value. For a simple read tool, it's minimally adequate but lacks depth for reliable agent 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?
Schema description coverage is 0%, but the description adds minimal value by implying the parameter is an 'ID'. However, it doesn't explain the ID format, source, or constraints beyond what's obvious from the schema's property name 'article_id'. With one parameter, the baseline is 4, but the description's lack of detail reduces it to 3.
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 the verb ('Get') and resource ('knowledge article by ID'), making the purpose specific and understandable. However, it doesn't differentiate from sibling tools like 'list_articles' or 'update_article', which would require explicit comparison to achieve a score of 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 provides no guidance on when to use this tool versus alternatives like 'list_articles' for browsing or 'update_article' for modifications. It lacks context about prerequisites or exclusions, leaving the agent to infer usage from the tool 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 carries full burden. It states this is a 'Get' operation, implying read-only behavior, but doesn't disclose any behavioral traits such as authentication requirements, rate limits, error conditions, or what 'detailed information' entails. This is inadequate for a tool with no annotation coverage.
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, efficient sentence that front-loads the core purpose without unnecessary words. Every part of the sentence contributes directly to understanding the tool's function, making it appropriately concise.
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?
Given no annotations, 0% schema description coverage, and no output schema, the description is incomplete. It lacks details on behavior, parameter usage, return values, and context relative to siblings. For a tool in a complex environment with many siblings, this minimal description leaves significant 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 description coverage is 0%, so the description must compensate. It mentions 'a specific changeset,' which implies the 'changeset_id' parameter, but doesn't add meaning beyond what's inferred from the schema's property names. Since there's only one parameter, the baseline is 4, but the description fails to explain the parameter's significance or format, lowering the score.
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 the verb ('Get') and resource ('detailed information about a specific changeset'), making the purpose unambiguous. However, it doesn't distinguish this tool from potential siblings like 'get_change_request_details' or 'get_workflow_details' beyond the resource type, which prevents a perfect score.
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. With siblings like 'list_changesets' and 'get_change_request_details' available, there's no indication of context, prerequisites, or comparative use cases, leaving the agent to infer usage.
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 carries full burden. 'List incidents' implies a read operation, but it doesn't disclose pagination behavior (though schema shows limit/offset), sorting defaults, permission requirements, rate limits, or what the output format looks like. For a listing tool with 6 parameters, this leaves significant behavioral gaps.
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, efficient sentence with zero wasted words. It's appropriately sized for a basic listing tool and front-loads the essential information.
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 tool with 6 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what constitutes an 'incident' in ServiceNow context, what fields are returned, how results are ordered, or any ServiceNow-specific behaviors. The agent would need to rely heavily on the schema alone.
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 0%, but the description provides no parameter information beyond what's implied by 'list incidents.' The schema documents 6 parameters with good descriptions, so the baseline is 3. The description adds no value beyond the schema's parameter documentation.
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 'List incidents from ServiceNow' clearly states the action (list) and resource (incidents) with the source (ServiceNow). It's specific enough to understand the basic function, though it doesn't differentiate from other list tools like list_articles or list_change_requests beyond the resource type.
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. With siblings like get_incident (presumably for single incidents) and update_incident, there's no indication of when listing is preferred over getting individual incidents or how this relates to incident management workflows.
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-mcp MCP server](https://glama.ai/mcp/servers/shameerampcome/servicenow-mcp/badges/card.svg)](https://glama.ai/mcp/servers/shameerampcome/servicenow-mcp)

Score Badge

Copy to your README.md:

[![servicenow-mcp MCP server](https://glama.ai/mcp/servers/shameerampcome/servicenow-mcp/badges/score.svg)](https://glama.ai/mcp/servers/shameerampcome/servicenow-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/shameerampcome/servicenow-mcp'

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