Skip to main content
Glama

Nausika

by app.nausika

Get Ratings

nausika_get_ratings
Read-onlyIdempotent

View ratings for a place (aggregate + your own) or list all your ratings.

Inputs: place_id, my_only, limit, offset.

Examples:

  • Place ratings: place_id="a1b2c3d4" (8-char short-id or full UUID)

  • My ratings: my_only=true

Tip: ratings are visible in nausika_search_places results to help other sailors.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMax results
offsetNoOffset for pagination
my_onlyNoList only your own ratings
place_idNoGet ratings for a specific place — full UUID or 8+ char hex prefix from nausika_search_places

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNo
offsetNo
ratingsNo
aggregateNo
my_ratingNo

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds behavioral detail beyond annotations: it explains the two distinct output modes (aggregate+own vs. own-only) and notes that ratings appear in search results. This is useful context that complements the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-organized with a brief overview, input list, examples, and a helpful tip. It's not overly verbose, though the tip about search results is slightly tangential. Overall, every section earns its place.

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?

With an output schema present, return values are covered. The description handles the two primary usage contexts (place ratings and my ratings) and parameter combinations implied by examples. Minor gaps like behavior when both place_id and my_only are set are not addressed, but the complexity is moderate and adequately covered.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so a baseline of 3 applies. The description adds extra meaning by clarifying place_id accepts either a full UUID or an 8-char short-id, and gives concrete examples for limit/offset usage. This adds value beyond the schema's property descriptions.

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 a specific verb and resource: 'View ratings for a place (aggregate + your own) or list all your ratings.' It clearly distinguishes the two main modes and differentiates from sibling tools like nausika_manage_rating, which presumably handles write operations.

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?

Provides clear context through examples: use place_id for place ratings, my_only=true for your own. It implies when to use this read-only tool versus write tools like nausika_manage_rating. No explicit exclusions, but the examples give actionable usage guidance.

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

All Nausika toolsInspect
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

A4.1/5.0
Disambiguation5/5

Every tool targets a clearly distinct resource and action. The get_* vs manage_* pairs are cleanly separated between read and mutation, and search/geocode/convert each handle different geospatial tasks. There is no meaningful overlap between tools like marine_forecast, seasonal_forecast, and tides.

Naming Consistency4/5

Most tools follow a consistent nausika_<verb>_<object> pattern (get_place, manage_rating, search_places). A few tools like nausika_calculator and nausika_tides are single nouns, which slightly breaks the pattern, but all names are lowercase snake_case and share the nausika_ prefix so the convention remains readable and predictable.

Tool Count3/5

With 19 tools, the set is on the heavier side of the ideal range. The domain (marine navigation, weather, places, routes, and user data) is broad enough to justify the count, but it crosses into the borderline zone where some tools could potentially be consolidated (e.g., manage_* tools share the action-param pattern and could be one generic tool).

Completeness4/5

The tool surface covers the core domain thoroughly: geocoding, place discovery/detail, routing, weather forecasts (short and seasonal), tides, and user-managed resources like boats, favorites, ratings, and routes. Minor gaps exist (e.g., no weather warning/alerts tool, no bulk operations), but most workflows can be completed without dead ends.

Resources