Skip to main content
Glama
ServiceNow_Developer_Panel

ServiceNow_Developer_Panel

add_tables

Read-only

Extend a cached multi-table response by fetching only the new ServiceNow tables, enabling query_cache joins without refetching existing data; expired caches return a new cache name.

Instructions

Add tables to a response cached by request_tables, so query_cache can join them with the tables it already holds. Only the new tables are fetched. If the cached response has expired, every table is requested again into a new cached response and the returned cache_name changes. Returns the same summary as request_tables, for every table of the response.

Input Schema

NameRequiredDescriptionDefault
tablesYesThe tables to add, each with its own query, fields and limit. A table already in the cached response cannot be added again.
cache_nameYesThe cache_name returned by request_tables or add_tables, or listed by list_cached_responses with request_type multiple_tables.

Output Schema

NameRequiredDescriptionDefault
sourceYes
sectionsYes
warningsYes
row_countYes
cache_nameYes
elapsed_msYes
executed_atYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.7/5.0
Behavior5/5

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

Beyond the read-only and open-world annotations, it discloses incremental fetching and the non-obvious expiry path: every table is refetched, a new cached response is created, and the returned cache_name changes. It also clarifies that the returned summary covers every table, not only the additions.

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?

Four compact sentences progress from purpose to fetch behavior, expiration behavior, and result scope. Every sentence provides operationally useful information without filler or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The rich input schema and output schema cover argument and return details, while the description supplies the workflow and cache-lifecycle context needed for correct invocation. The expiration warning and changed cache_name address especially important non-obvious behavior.

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

Parameters4/5

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

With 100% schema coverage, the schema already documents both arguments and their query options. The description adds useful lifecycle semantics for cache_name and clarifies that the supplied tables are incremental additions, including how expiration affects the cache identifier.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence specifies the operation and resource: extending a response cached by request_tables with additional tables for query_cache joins. Naming both sibling tools distinguishes this from creating a cached response and querying one.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It establishes the prerequisite of an existing request_tables cache and explains the intended downstream use with query_cache. It does not explicitly state when not to use it or direct agents to request_tables when starting a fresh cached response.

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