Skip to main content
Glama
Sign In
bearded-giant

spaceship-mcp

by bearded-giant
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Create PTR Record

create_ptr_record
DestructiveIdempotent

Create a PTR (reverse DNS) record for a domain, replacing existing PTR records with the same name; list records first to avoid overwriting.

Instructions

Create a PTR record (reverse DNS pointer) for a domain. WARNING: This replaces ALL existing PTR records with the same name — previous PTR records for this name will be overwritten, not merged. Use list_dns_records first to check for existing records.

Input Schema

NameRequiredDescriptionDefault
ttlNoTTL in seconds
nameYesRecord name
domainYesThe domain name
pointerYesPointer target hostname (e.g. "host.example.com")

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.0

TDQS

A4.7/5.0
Behavior5/5

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

Annotations (destructiveHint=true) already indicate potential destruction. The description adds crucial context: it replaces all existing PTR records, overwriting them, not merging. This goes beyond annotations, fully disclosing the overwrite 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 two sentences: first states core purpose, second delivers critical warning. No redundant text, every sentence earns its place. Concise and front-loaded with essential information.

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

Completeness5/5

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

Given 4 parameters, no output schema, and annotations covering safety profile, the description provides complete context: purpose, destructive behavior, and prerequisite action (check existing records). No gaps remain for an AI agent to select and invoke correctly.

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?

Input schema has 100% coverage with all four parameters (domain, name, pointer, ttl) described. The description does not add parameter-specific details beyond the schema. Baseline 3 is appropriate as schema handles semantics adequately.

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

Purpose5/5

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

The description clearly states the tool creates a PTR record for a domain, using specific verb 'Create' and resource 'PTR record'. It distinguishes from sibling create_*_record tools by targeting reverse DNS, and includes a warning about overwriting behavior, enhancing clarity.

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?

The description explicitly warns that the tool replaces all existing PTR records with the same name, not merging, and advises using list_dns_records first to check. This provides clear when-to-use and when-to-avoid guidance, plus an alternative tool reference.

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