Skip to main content
Glama

get_discovery_run

Read-onlyIdempotent

Get one Discovery run by sys_id or number (DIS...), including full status fields

Instructions

Get one Discovery run by sys_id or number (DIS...), including full status fields

Input Schema

NameRequiredDescriptionDefault
run_idYesdiscovery_status sys_id or number (e.g. "DIS0001001")

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.15.1

TDQS

B3.4/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so safety and repeatability are covered. The phrase 'including full status fields' adds a small hint about the payload's richness, but nothing about what happens on an unknown sys_id or DIS number, and there is no output schema to lean on.

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?

One short sentence with the verb and identifier forms front-loaded and no filler. 'Including full status fields' is slightly loose phrasing but does add a hint about the returned content, so every clause earns its place.

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

Completeness3/5

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

For a simple single-record read with full schema coverage and read-only annotations, this is close to sufficient. It is still silent on how the tool relates to list_discovery_runs and on failure behavior for a bad identifier, leaving small but real gaps.

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

Parameters3/5

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

Schema coverage is 100% and the single parameter already documents both accepted identifier forms with an example. The description merely repeats that ('by sys_id or number (DIS...)') without adding format rules, fallback behavior, or constraints, so it is baseline-adequate only.

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?

States a specific verb ('Get') and resource ('one Discovery run') plus the identifier formats accepted, which is more than the bare name conveys. It does not distinguish itself from the sibling list_discovery_runs, so an agent must infer that this is the single-record counterpart.

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

Usage Guidelines3/5

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

Usage is only implied: needing one run's full detail. There is no explicit 'use list_discovery_runs to enumerate' guidance despite that sibling existing in the tool set, and no note on prerequisites for looking up a run.

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

Deploy Server

Other Tools