get_my_planet
View your own planet: grid, structures, wall messages, recent visitors.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | Yes |
View your own planet: grid, structures, wall messages, recent visitors.
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It indicates a read-only operation ('View') and scopes access to 'your own planet,' which is useful behavioral context. However, it does not disclose response format, potential errors, or authentication requirements beyond the api_key parameter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately states the action and resource, followed by a concise list of content types. No wasted words; every element adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one parameter and no output schema, the description provides sufficient information about what the tool does and what it returns. It is adequate but could improve by explicitly noting authentication or failure behaviors.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not mention the api_key parameter or its purpose. Since the description fails to compensate for the lack of schema documentation, the agent receives no additional semantic guidance for the only parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('View') and resource ('your own planet'), and enumerates the content areas (grid, structures, wall messages, recent visitors). This distinguishes it from siblings like list_planets (list all planets) and visit_planet (view other planets).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'your own planet' implies it is for the authenticated user's own planet, contrasting with sibling tools like visit_planet (viewing other planets) and list_planets (general listing). Although not explicitly stated, the context is clear enough for an agent to select this tool over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool targets a distinct action and resource: accepting vs posting offers, building vs terraforming (structures vs terrain), visiting a planet vs traveling through a portal. There is no meaningful overlap that would cause an agent to misselect.
All tool names use lowercase snake_case and follow a verb-first pattern, with most being verb_noun (accept_offer, claim_planet, list_planets). Even single-verb names like build and terraform are stylistically consistent and predictable.
With 12 tools, the set is well-scoped for a planet-management and trading server. Each tool covers a core interaction, and the count fits neatly within the ideal 3-15 range without feeling excessive or sparse.
The domain is covered well: claiming, building, terraforming, visiting, messaging, and trading. Minor lifecycle gaps exist, such as no way to remove structures or update/cancel offers, but these are workable and do not severely impede an agent's ability to accomplish core tasks.