Atlarium Habitat Database MCP

Suggest habitat for tank

suggest_habitat_for_tank

Read-onlyIdempotent

Suggest a complete public habitat plan with species, plants, products, warnings, motivations and related guides.

Input Schema

TableJSON Schema

Name	Required	Description
`gh`	No	Water hardness, conductivity or TDS-style value for advisory matching.
`kh`	No	Water hardness, conductivity or TDS-style value for advisory matching.
`ph`	No	Water pH value on the 0 to 14 scale.
`co2`	No	CO2 setup level for the suggested habitat.
`tds`	No	Total dissolved solids value for habitat matching.
`limit`	No	Maximum number of suggestions to return, up to 30.
`language`	No	Optional preferred response language: it, en or es.
`water_type`	No	Target habitat water or environment type.
`light_level`	No	Lighting intensity preference for the suggested habitat.
`tank_liters`	Yes	Tank or habitat volume in liters.
`temperature`	No	Water or ambient temperature in degrees Celsius.
`planted_tank`	No	When true, prefer plans designed for planted aquariums.
`setup_intent`	No	Primary setup intent for the habitat plan.
`beginner_friendly`	No	When true, prefer beginner-friendly habitat plans.
`target_difficulty`	No	Desired care difficulty for the habitat plan.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`data`	Yes
`tool`	Yes

TDQS

A4/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, so the safety profile is covered. The description adds that the plan includes species, plants, products, warnings, motivations, and guides, which gives useful behavioral context about the scope of the result. This is helpful, though not rich enough to exceed a baseline given the strong annotations.

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 a single sentence, 17 words, with the verb and object front-loaded. Every phrase adds value ('complete', 'public', listing of plan components). No redundant information.

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?

Despite having 15 parameters and an output schema, the description sufficiently conveys the tool's core purpose and result composition. The output schema likely covers the return structure. The description is brief but complete for the agent to decide invocation, though it could mention how parameters influence the plan.

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 description coverage is 100% and all parameters are documented in the schema. The description does not add any extra meaning to any specific parameter, but the schema already handles this. Per the baseline rule for high coverage, a 3 is appropriate.

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 states it 'Suggest a complete public habitat plan with species, plants, products, warnings, motivations and related guides.' This uses a specific verb ('suggest') and resource ('habitat plan') while enumerating the plan's components, clearly differentiating it from the sibling 'suggest_species_for_tank' which focuses only on species.

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

Usage Guidelines4/5

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

The description clearly implies when to use this tool: when a complete habitat plan is needed rather than a single-species suggestion. However, it does not explicitly state exclusions or name alternatives, so it misses the 'when-not / alternatives' bar for a 5.

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

All Atlarium Habitat Database MCP tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.7/5.0

Disambiguation5/5

Each tool has a unique name and clearly documented purpose. The 'get_' and 'search_' pairs are explicitly linked via slugs, and the 'calculate_', 'check_', 'convert_', 'generate_', 'list_', 'match_', and 'suggest_' tools all address distinct operations. There is no ambiguity or overlap.

Naming Consistency5/5

All 39 tools follow a consistent verb_noun pattern in snake_case (e.g., calculate_tank_volume, search_plants, get_fish_profile). No mixing of conventions or non-standard naming is present.

Tool Count2/5

With 39 tools, the set is far above the typical well-scoped range of 3-15. While the domain is broad, the sheer number makes the tool surface heavy and potentially overwhelming for an agent to navigate effectively.

Completeness5/5

The tool set covers the entire domain of an aquarium habitat database: calculations, unit conversion, species compatibility, profile retrieval for all entity types, diagnostic matching, and habitat suggestion. No obvious gaps exist for a read-only advisory API.

Suggest habitat for tank

Input Schema

Output Schema

TDQS

Glama MCP Gateway

TDQS

Resources