get_passive
Look up a passive skill in Palworld: id, name, description, effects. Free tier: 20 calls/day per IP.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| skill | Yes | Passive skill name or id (e.g. "Swift" or "swift"). |
Look up a passive skill in Palworld: id, name, description, effects. Free tier: 20 calls/day per IP.
| Name | Required | Description | Default |
|---|---|---|---|
| skill | Yes | Passive skill name or id (e.g. "Swift" or "swift"). |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It mentions the rate limit ('Free tier: 20 calls/day per IP') and lists return fields, providing useful context. However, it does not explain behavior for unknown skills, error handling, or any limitations beyond the rate limit, so the transparency is partial.
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 extremely concise and front-loaded, with the core action and resource in the first few words. The second sentence adds a critical operational detail (rate limit). Every word earns its place, and there is no redundancy or filler.
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?
Given the tool's simplicity (one parameter, no output schema), the description is fairly complete. It communicates the return fields (id, name, description, effects) and the rate limit, which are key for an agent. However, it omits any mention of behavior for missing or invalid input, which would make it fully complete.
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 100%, and the schema fully explains the 'skill' parameter with an example. The description does not add further semantic meaning beyond what the schema provides, so the baseline of 3 is appropriate.
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 and resource: 'Look up a passive skill in Palworld.' It also lists the key fields returned (id, name, description, effects), distinguishing it from sibling tools that focus on breeding routes, breeding children, pal info, and pal search.
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 description implies when to use this tool (when needing passive skill details) but provides no explicit guidance on when to avoid it or which sibling tool to use instead. The sibling names suggest alternatives, but the description itself doesn't offer usage boundaries or exclusions, leaving the agent to infer from context.
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 serves a clearly distinct purpose: searching Pals, fetching Pal details, looking up passives, finding breeding routes, and calculating breeding offspring. No overlap or ambiguity exists.
All tool names follow a consistent verb_noun pattern with lowercase and underscores: find_breeding_routes, get_breeding_child, get_pal_info, get_passive, search_pals. The naming is predictable and uniform.
With 5 tools, the set is well-scoped for a Palworld breeding assistant, covering the essential operations without unnecessary bloat. This is an appropriate size for the domain.
The toolset fully covers the breeding-related domain: searching, detailed Pal info, passive skills, breeding routes, and direct offspring calculation. There are no obvious gaps for the stated purpose.