Atlarium Habitat Database MCP

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds no further behavioral traits (e.g., what output format, if errors occur, or limitations). With annotations present, a score of 3 indicates it meets the minimum bar but does not enrich beyond structured data.

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 sentence of 10 words, efficiently conveying the core purpose without unnecessary words. However, it could be slightly longer to include parameter context without becoming bloated.

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 has 7 parameters, no output schema, and no parameter descriptions, the description is severely incomplete. It does not explain what 'basic compatibility information' entails, how optional parameters affect results, or what the output looks like. Sibling tools like suggest_species_for_tank imply alternative approaches, but no differentiation is provided.

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%, yet the description does not explain the meaning or usage of any of the 7 parameters (e.g., what gh, kh, ph, etc. represent, or that species is required). It fails to compensate for the missing schema descriptions, leaving the agent to guess parameter semantics.

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 checks basic compatibility information between habitat species, specifying the verb 'check', the resource 'compatibility information', and the context 'between habitat species using Atlarium data'. It distinguishes from sibling tools like get_fish_profile or search_fish by focusing on compatibility rather than single species profiles.

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 usage for checking compatibility but provides no explicit guidance on when to use this tool versus alternatives like suggest_species_for_tank, nor any prerequisites or exclusions. The purpose is clear but not contextualized among siblings.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint. Description adds only 'structured profile' which is vague and does not provide meaningful behavioral details beyond annotations.

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?

Single sentence with no wasted words, but over-condensed to the point of omitting essential details. Balance between conciseness and completeness not achieved.

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?

With 2 parameters, no output schema, and siblings, description is incomplete. No return format, no parameter details, no usage context. Leaves agent guessing.

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%, yet description provides no explanation of parameters. Neither slug nor language are described, so agent cannot understand what values to provide.

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?

Description clearly states verb (get), resource (fish or aquatic animal profile), and source (Atlarium habitat database). Distinguishes from siblings like search_fish and get_plant_profile.

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?

No guidance on when to use this tool vs alternatives like search_fish. Missing context about prerequisites or typical use cases.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, providing a clear safety profile. The description adds no further behavioral context beyond the basic action, but it does not contradict annotations. A score of 3 is appropriate as the description adds no extra value beyond the structured fields.

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 very concise at one sentence, but it is too brief given the lack of parameter information. It does not front-load key details and the single sentence does not provide enough value for its length.

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?

With two parameters, no output schema, and rich annotations, the description is incomplete. It does not explain what a 'structured guide' is, how the 'slug' parameter works, or how 'language' affects the output. Given the context signals, more detail is needed.

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%, meaning the description must explain the parameters. However, the description does not mention 'slug' or 'language' at all, leaving the agent to infer their meaning solely from the schema, which lacks descriptions. This is a significant gap.

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 'Get a structured guide from Atlarium' uses a specific verb ('get') and resource ('structured guide'), clearly stating the tool's action. However, it does not differentiate it from sibling tools like search_guides, which could be used to find guides before retrieving one.

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?

No guidance is provided on when to use this tool versus alternatives. The sibling tools include search_guides, suggesting get_guide is for retrieving a specific guide by slug, but this is not explicitly stated.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is provided. The description adds minimal behavioral context beyond 'structured' and does not mention rate limits, permissions, or return format.

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 sentence, which is concise, but it lacks substantive content. It is not overloaded, but it also does not earn its place with valuable information.

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 lack of output schema, zero schema description coverage, and only two parameters, the description is insufficient. It does not explain what a 'structured aquatic plant profile' contains or how the language parameter affects the output.

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%, meaning the input schema provides no parameter descriptions. The tool description also fails to explain the parameters 'slug' or 'language', leaving the agent without critical semantic information.

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 'Get a structured aquatic plant profile', specifying the verb ('Get') and the resource ('aquatic plant profile'), which distinguishes it from siblings like get_fish_profile or get_product_profile.

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 usage for retrieving a specific plant profile, but lacks explicit guidance on when to use this tool versus alternatives like search_plants or suggest_species_for_tank. However, the purpose is clear enough for an agent to infer context.

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

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

The description adds no behavioral context beyond what annotations (readOnlyHint, idempotentHint) already provide; it doesn't mention response format, prerequisites, or any side effects.

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 very short and efficient, but it sacrifices informativeness; it's concise but under-specified.

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?

With no output schema and only two parameters, the description fails to explain what a 'structured habitat product profile' contains, leaving the agent guessing about the return structure.

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 tool description does not explain the parameters (slug, language) or their role; the agent gets no help understanding what values to provide.

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 verb ('Get') and resource ('product profile'), but it does not differentiate from sibling tools like get_fish_profile or get_plant_profile, though the resource name is distinct enough.

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?

No guidance on when to use this tool vs alternatives such as search_products or other profile getters; the agent receives no context for decision-making.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, indicating safe, idempotent behavior. The description adds no additional behavioral context beyond 'Get', such as what happens if a species is not found, whether results are cached, or the format of the parameters. With annotations covering safety, the description contributes minimal value.

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, concise sentence of 12 words, with no redundant information. It is well-structured and front-loaded for quick scanning.

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 has 3 parameters (2 required) and no output schema, the description is too sparse. It does not explain what 'water parameters' include (e.g., pH, temperature), how the 'language' parameter affects results, or whether the output is a single set or a range. An agent would lack sufficient context to use the tool effectively.

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%, meaning the schema does not document parameters with descriptions. The tool description also provides no information about the meaning, format, or constraints of the three parameters (slug, type, language). This is a critical gap that hinders correct parameter selection.

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 verb 'Get' and the resource 'recommended water parameters for an aquatic species or plant', making the purpose unambiguous. It distinguishes itself from sibling tools like 'get_fish_profile' or 'suggest_species_for_tank'.

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 usage for fetching water parameters for a specific species or plant, but it does not provide explicit guidance on when to use this tool versus alternatives like 'suggest_species_for_tank' or 'search_fish'. No when-not-to-use or alternatives are mentioned.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true. Description adds no further behavioral context (e.g., rate limits, authentication, or result details).

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?

Single sentence is concise but lacks structure; no front-loading beyond the verb. Could be improved by adding a brief summary of key parameters.

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?

With 16 parameters, a missing output schema, and many sibling tools, the description is too sparse to fully guide an agent. No mention of pagination, ordering, or typical use cases.

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 provides zero information about any of the 16 parameters (e.g., what gh, kh, ph mean). Agents must infer meaning from parameter names alone.

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?

Clearly specifies verb 'search' and resource 'fish and aquatic animal profiles'. Distinguishes from sibling tools like get_fish_profile (single fish retrieval) and search_plants (different resource).

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?

No explicit guidance on when to use this tool vs alternatives like get_fish_profile or search_guides. Usage is implied by the name 'search_fish' but lacks context for selection.

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

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

Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds no additional behavioral context (e.g., pagination, result format). With annotations present, the description's lack of extra detail is acceptable but not valuable.

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, concise sentence with no wasted words. However, it misses important details that could be structured without adding verbosity. Given the minimalism, it scores well on conciseness but not on structure.

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?

With 5 parameters, no output schema, and no parameter descriptions, the description is incomplete. It does not explain what fields are searchable, how to use the language filter, or how pagination works, leaving the agent inadequately informed.

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%, so the description must explain parameters. It does not describe any of the 5 parameters (query, topic, limit, offset, language) or their semantics. This is a critical gap.

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 searches 'Atlarium habitat guides and educational content', providing a specific verb and resource. It distinguishes from sibling tools like get_guide (search vs. retrieve) and other search tools (fish, plants). However, it could be more specific about the scope (e.g., 'guides on habitats and education').

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?

No guidance on when to use this tool versus alternatives like get_guide, search_fish, etc. There is no mention of context or prerequisites, leaving the agent to infer usage from the name alone.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds no additional behavioral traits (e.g., pagination, result format, or special constraints).

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 very short (one sentence), which is concise, but it fails to provide necessary detail. The sentence is front-loaded with the purpose but does not earn its place by adding value beyond the title.

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 high complexity (9 parameters, no output schema, 0% schema coverage), the description is completely inadequate. It does not explain return values, parameter usage, or how this tool fits with siblings.

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%. The description does not explain any of the 9 parameters (query, limit, offset, language, placement, difficulty, growth_rate, co2_requirement, light_requirement). This is a severe deficiency.

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 explicitly states 'Search aquatic plants in the Atlarium database.' This is a specific verb (Search) and resource (aquatic plants), and it distinguishes the tool from sibling search tools for fish, guides, and products.

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?

No guidance is provided on when to use this tool versus alternatives like check_species_compatibility, get_plant_profile, or suggest_species_for_tank. The description does not clarify the context or prerequisites for searching plants.

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

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

Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds no further behavioral details beyond stating it is a search operation.

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?

Single sentence that is front-loaded with the core purpose. No extraneous content; every word earns its place.

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 has 7 parameters and no output schema, the description is too sparse to be complete. It lacks guidance on parameter usage, output expectations, and behavioral context beyond basic search.

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 entirely fails to explain the meaning or usage of the 7 parameters. Without any param info in the description, the tool is hard to use correctly.

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?

Description clearly states the tool searches habitat products for aquariums and terrariums in the Atlarium database, specifying the verb 'Search' and resource 'products'. It effectively distinguishes from sibling tools like search_fish and search_plants.

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?

Description implies usage for product searches but provides no explicit guidance on when to use this over alternatives like search_fish or search_guides. No exclusions or context are mentioned.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, clearly indicating a safe read operation. The description adds no further behavioral context (e.g., whether results are ranked, limited, cached). With annotations covering the safety profile, a score of 3 is appropriate.

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, well-structured sentence with no unnecessary words. It captures the core purpose immediately.

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?

With 9 parameters, no output schema, and no description of return values (what does 'suggest' return? species names? IDs?), the description leaves significant gaps. It fails to mention the optional result limit or language preference, which are critical for using the tool effectively.

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%, so the description must compensate. It mentions 'tank size' (tank_liters) and 'water parameters' (gh, kh, ph, temperature), but ignores 4 other parameters: limit, language, planted_tank, and beginner_friendly. Users get no guidance on these important filtering options.

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 suggests compatible aquatic species based on tank size and water parameters. This distinguishes it from siblings like 'check_species_compatibility' which likely checks specific pairs, and 'search_fish' which may return all species without compatibility filtering.

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 usage for getting species suggestions given tank parameters, but it does not explicitly mention when to prefer this over alternatives like 'check_species_compatibility' or 'search_fish'. No when-not-to-use guidance is provided.

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