Skip to main content
Glama
laserdata

LaserData Docs MCP

Official
by laserdata

get_related_docs

Read-only

Find documentation pages related to a given doc key via explicit links, backlinks, shared sections, and shared vocabulary. Use after retrieving one page when it lacks full context for a complete answer.

Instructions

Return documentation pages related to one doc key.

Relatedness comes from explicit links, backlinks, shared section, and shared vocabulary. Use this after get_doc when one page may not contain all context needed for a complete answer.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
keyYes
max_resultsNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds genuinely useful behavioral context by disclosing how relatedness is computed (links, backlinks, shared section, shared vocabulary), which tells the agent how much to trust results. It does not discuss result limits or ordering beyond the max_results default.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, front-loaded with the purpose followed by the usage cue; no filler and nothing buried.

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

Completeness4/5

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

With an output schema present, return format need not be explained, and annotations carry the safety profile. Purpose, relatedness model, and usage timing are complete; only the max_results parameter's semantics and any result-limit behavior are left unaddressed.

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% and there are two parameters. The phrase 'one doc key' clarifies that the required key is a document key, but max_results is never explained in the schema or the description, so the agent must guess at its meaning and behavior.

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?

States a specific verb (Return) and resource (documentation pages related to one doc key), and enumerates the four sources of relatedness (explicit links, backlinks, shared section, shared vocabulary), which makes its output conceptually distinct from siblings like get_doc or search_docs.

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

Usage Guidelines5/5

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

Explicitly names the alternative and the triggering condition: 'Use this after get_doc when one page may not contain all context needed for a complete answer.' The sequencing and the reason to escalate are both stated, leaving little to inference.

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