Ocean data for any coast or sea, Australian marine park facts and Marxan reserve design.
Scored across 12 tools
Most tools target clearly distinct actions and resources, such as project data upload versus project listing or marine park lookup. The main ambiguity is among find_layers, look_here, and look_in_area, which all surface layers but differ by keyword, point, and polygon; descriptions clarify this, but an agent could still hesitate between them.
All names use snake_case and mostly follow a verb-first pattern, making the set readable and predictable. Minor deviations like the bare simulate and the less conventional look_here/understand_area keep it from being perfectly consistent.
Twelve tools is well-scoped for a marine data platform that combines discovery, project data management, area analysis, and research search. Each tool appears to earn its place without obvious redundancy or bloating.
Discovery, project inspection, data upload, and analysis are covered, but project lifecycle coverage is incomplete: there is no create_project, update_project, delete_project, or remove/edit project data operation. simulate is also restricted to the example project, limiting the apparent planning workflow.
Add data to a project from a public download link (GeoPackage, zipped Shapefile, GeoJSON, KML, CSV with coordinates or GeoTIFF, up to 200 MB): your own model's output, a survey, a map. Side effect: the file is downloaded, stored and added to the project, where its team can see it; nothing is deleted or overwritten. Biohotspot then checks it; follow its status with list_project_data and finish anything it asks for in the project's Uploads tab. Needs owner or editor rights.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| year | No | ||
| title | No | ||
| source | No | Who made it | |
| licence | No | cc-by, cc0, cc-by-nc, other-open, restricted or unsure | |
| project_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations by disclosing the side effects: the remote file is downloaded, stored and made visible to the project team, and nothing existing is deleted or overwritten. It also reveals that the request is asynchronous — Biohotspot checks the upload afterwards and may require action in the Uploads tab — which an agent could not infer from destructiveHint=false alone.
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 purpose and the side-effect warning are front-loaded in the first two clauses, so an agent can decide quickly. It is dense rather than bloated, though the illustrative list ('a survey, a map') and the multi-clause parenthetical cost some readability.
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 write tool with no output schema, it covers side effects, permission requirements, async status tracking and input constraints — enough to invoke it safely. The remaining gap is what the call returns (an id or job handle) and how the post-upload 'checks' manifest, which the agent must discover via list_project_data.
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 coverage is only 33% (source and licence only), so the description must compensate, and it does add real meaning for 'url': public link, accepted formats, 200 MB ceiling. However, 'year' and 'title' get no explanation at all, and it does not say whether the URL must be anonymously reachable, so the gap for four of six parameters is only partly filled.
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?
States a specific verb and resource (add data to a project) plus the input channel (a public download link) and the accepted formats and size cap. This cleanly separates it from read-side siblings such as list_project_data, get_project and find_layers, which never mutate a project.
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?
Gives concrete use cases ('your own model's output, a survey, a map') and an explicit follow-up route: check processing with list_project_data and complete any prompts in the Uploads tab. It also states the permission prerequisite (owner or editor rights). It stops short of naming when NOT to use it (e.g. adding local files or existing platform layers).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find Biohotspot map layers by words (e.g. 'seagrass', 'coral bleaching') among its 1,600+ world layers. Returns ids, names, categories and licences (25 by default); vector layers can then be read with get_features. Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint/openWorldHint/destructiveHint, and the description adds substantive context beyond them: the returned fields (ids, names, categories, licences) and the default result size of 25. The trailing 'Read-only' restates the annotation but the rest is genuinely additive; pagination or total-count behavior is not covered.
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?
Two compact sentences: the search scope and corpus size come first, then the return fields and the chaining hint. Nothing is padded, though 'Read-only' is mild redundancy against the annotations.
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, the description usefully enumerates what comes back, and it names the default limit. It lacks detail on how to raise the limit, whether counts are returned, and what non-vector layers are good for after being found.
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 coverage is 0%, so the description must carry the load, and it does for `query` by characterizing it as free-text words with concrete examples ('seagrass', 'coral bleaching'). The '25 by default' phrasing implies the `limit` parameter's default without naming or bounding it, which is good but not complete.
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?
States a specific verb and resource ('Find Biohotspot map layers by words') plus the corpus searched (1,600+ world layers) and gives example queries. It also distinguishes itself from the sibling get_features by casting itself as the discovery step that feeds it.
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?
Clear usage context: keyword search over the layer catalogue, with an explicit follow-up path ('vector layers can then be read with get_features'). It does not name when to prefer it over siblings like look_here or look_in_area, so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a vector layer's features as GeoJSON from Biohotspot's OGC API, optionally inside a bounding box [west, south, east, north]; up to limit features (500 by default, 5,000 at most). Collection ids: find_layers ids, or exmouth_ for the example project's open layers. Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
| bbox | No | ||
| limit | No | ||
| collection | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint/openWorldHint/destructiveHint, so 'Read-only' is redundant, but the description adds genuinely new behavior: GeoJSON output format, default page of 500 and a hard ceiling of 5,000 features. It does not mention pagination past the cap or error behavior when a collection id is invalid.
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?
A single front-loaded sentence: the action and output format come first, then optional constraints, then collection id conventions. Every clause (bbox ordering, limit cap, id sourcing) carries information the agent needs.
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, the description still names the return format (GeoJSON) and bounds the result volume. All three parameters are explained and the required collection id's provenance is resolved, leaving nothing essential unstated for correct invocation.
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 fully compensates: bbox axis order [west, south, east, north] is spelled out, limit's default (500) and maximum (5,000) are given, and collection is tied to find_layers ids. These are semantics the schema alone cannot convey.
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?
States a specific verb and resource ('Get a vector layer's features as GeoJSON from Biohotspot's OGC API'), which is clearly distinct from the sibling find_layers that only enumerates layers. The bbox and limit scoping further pins down what the call returns.
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?
It routes the agent to the correct prerequisite by naming find_layers as the source of collection ids, and says use exmouth_<dataset> for example project layers. There is no explicit when-not guidance or mention of alternatives like look_in_area, which keeps it from a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the facts about an Australian marine park from its Biohotspot page: area, IUCN categories and named zones (CAPAD 2024), habitats, blue carbon and pressures measured inside it, each with its source and licence, and the page's address. Give part of the park's name; state (wa, qld, nsw, vic, sa, tas, nt, com for Commonwealth waters) narrows it. Several matches return the list to choose from; parks under 10 km² or without enough open data have no page. Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Park name or part of it, e.g. 'Ningaloo' | |
| state | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false. The description adds genuine behavioral detail beyond that: ambiguous matches return a candidate list rather than a single result, and small/low-data parks are silently unavailable with no page. Return-field and data-source provenance (CAPAD 2024, licences) also adds context.
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?
Dense but front-loaded: the core purpose and returned facts come first, then the partial-name/state narrowing, then the edge cases. Every clause carries information, though the single run-on sentence could be broken up for scannability.
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, the description enumerates the returned fields and their provenance, explains matching and narrowing behavior, and discloses the no-page failure mode. An agent has everything needed to call this and interpret results without opening anything else.
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 coverage is only 50% (the `state` parameter has no schema description), and the description compensates by enumerating the accepted values (wa, qld, nsw, vic, sa, tas, nt, com for Commonwealth waters) and explaining that `name` accepts partial matches. This meaningfully exceeds what the schema provides, though minor details like case handling or default behavior remain unstated.
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?
States a specific verb and resource ('Get the facts about an Australian marine park from its Biohotspot page') and enumerates the returned content (area, IUCN categories, zones, habitats, blue carbon, pressures, sources/licences, address). This clearly separates it from siblings like look_in_area or understand_area, which operate on generic areas rather than marine-park Biohotspot pages.
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?
Gives concrete usage context: pass part of the park name, use `state` to narrow, several matches return a list to choose from, and parks under 10 km² or with insufficient open data have no page. It stops short of explicitly contrasting against alternative area tools, but the guidance for calling it correctly is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one of your projects: its area (GeoJSON), its data check (each data type covered, partial or missing) and your role. Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the 'Read-only' sentence is redundant but consistent. The description adds real value beyond annotations by disclosing the return contents, including the area GeoJSON and the partial/missing data-check states.
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?
A single compact sentence that front-loads the core action and lists return fields without waste. Every clause 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?
With no output schema and no annotations beyond safety hints, the description does the needed work of describing what comes back (area, data check, role). It stops short of covering error behavior for an unknown project_id, but is otherwise sufficient for a one-parameter read tool.
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?
There is a single parameter (project_id) with 0% schema description coverage, and the description never names or explains it. 'One of your projects' only loosely hints that an identifier is needed, without saying where it comes from or its format, so it barely compensates for the schema 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?
Names a specific verb (get) and resource (one of your projects) and enumerates the returned fields: area GeoJSON, data-check status per type, and your role. This clearly separates it from list_projects by implying a single record, though no sibling is named explicitly.
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?
Usage is only implied: 'one of your projects' suggests a specific project ID is required, implicitly coming from list_projects or similar. There is no explicit when-to-use versus list_projects/get_features, and no stated preconditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the data a project's team added, with each file's status (receiving, checked, ready, failed). Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and destructiveHint, and the description's 'Read-only' merely repeats that. It does add useful return-content detail (file status values: receiving, checked, ready, failed), but does not cover permissions, pagination, or error behavior.
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?
A single front-loaded sentence with no filler; the parenthetical status list is compact and useful.
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 one-parameter read-only list tool, the description is nearly complete: it states the resource and returned statuses, and annotations cover safety. It omits pagination/result-size expectations and explicit project_id validation details.
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?
With 0% schema description coverage, the description must carry project_id's meaning. It implies project_id identifies the project whose team's data is listed, but does not explain format, constraints, or failure cases.
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 gives a specific verb ('List') and resource ('data a project's team added') and even itemizes status values. It does not explicitly name the sibling add_project_data or contrast with list_projects/get_project, so it is clear but not fully sibling-differentiated.
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 when-to-use, prerequisites, or alternatives are stated beyond the implied read-only listing. An agent must infer that this is the read counterpart to add_project_data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List your Biohotspot projects and the ones shared with you: name, area, your role and how complete their data is. Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the 'Read-only' sentence is largely redundant. The description does add value by disclosing the returned fields (name, area, role, data completeness), but says nothing about ordering, result size, or pagination.
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?
A single efficient sentence that front-loads the scope and then enumerates returned fields. The trailing 'Read-only' duplicates the annotations and is the only wasted clause.
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 parameters and no output schema, the description carries the burden of explaining what comes back, and it does list the key fields. It stops short of noting result ordering or volume, which would help an agent decide whether to page through 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?
The tool takes zero parameters, so there is no parameter semantics to document. Baseline 4 applies; nothing in the description misleads about inputs.
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?
States a specific verb ('List') and resource ('Biohotspot projects'), and clarifies scope as owned plus shared projects. This distinguishes it from get_project (singular), though the sibling is never named explicitly.
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 'your projects and the ones shared with you' phrasing implies this is the broad enumeration entry point, but there is no explicit when-to-use guidance, no direction to get_project for detail, and no stated preconditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List every Biohotspot map layer with data within km of a point on the sea (a place being studied, not the user's location): habitats, wildlife, human uses, protected areas and world ocean maps, with a few values from each. Read-only. Use it to learn what a place holds.
| Name | Required | Description | Default |
|---|---|---|---|
| km | No | Radius in km (default 5) | |
| lat | Yes | Latitude of the place to look at, WGS84 | |
| lon | Yes | Longitude of the place to look at, WGS84 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so "Read-only" is redundant, but the description adds two things the annotations don't: the returned data is sampled ("a few values from each"), signalling that full records require get_features, and the coordinate refers to a studied place rather than the caller's location. Return shape, pagination and layer counts remain unstated.
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?
One substantive opening sentence carries the scope and output categories, front-loaded before the two short follow-ups. The layer enumeration is a little dense but each clause adds information; nothing is padding.
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, the description compensates by naming the layer families and noting that only a few values per layer come back, which is enough to set expectations. Only the absence of any guidance on sibling choice and result size keeps it below a 5.
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 coverage is 100%, so the baseline is 3; the description earns an extra point by interpreting the lat/lon pair as "a point on the sea (a place being studied, not the user's location)", which disambiguates a genuine ambiguity not resolved by the schema's plain "Latitude of the place".
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?
States a specific verb and resource (list Biohotspot map layers) with an explicit spatial scope and enumerated layer categories (habitats, wildlife, human uses, protected areas, world ocean maps). It does not distinguish itself from close siblings like look_in_area, understand_area, or find_layers, so an agent cannot tell from this text alone which of those to pick.
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?
"Use it to learn what a place holds" implies a reconnaissance use case, which is helpful framing. But there are no exclusions, no prerequisites, and no named alternative despite several neighbouring tools (look_in_area, understand_area, get_features) that plausibly overlap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List every Biohotspot map layer with data inside a polygon on the sea, with a few values from each. Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
| polygon | Yes | A GeoJSON Polygon (WGS84) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the description's 'Read-only' adds little. It does add useful return-shape context ('with a few values from each') and narrows the domain to sea polygons, but it does not explain empty results, result size, or spatial edge cases.
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 front-loaded and efficient, with the core action stated immediately. 'Read-only' is redundant with annotations, and the description is so terse that it omits useful routing and output detail, but it contains no wasted prose.
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 one-parameter spatial listing tool with safety annotations, this is mostly enough to invoke correctly. However, with no output schema, the vague phrase 'a few values from each' leaves the return shape unclear, and the description does not address empty results or how this differs from closely related 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 100%, and the only parameter is documented as a GeoJSON Polygon in WGS84. The description adds that the polygon is on the sea, which is mildly useful, but it does not clarify coordinate constraints, land polygons, holes, or validity requirements beyond the schema.
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?
States a specific verb and resource: list every Biohotspot map layer with data inside a sea polygon, including a sample of values. This is clear, but it does not distinguish the tool from siblings such as look_here, understand_area, find_layers, or get_features.
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 spatial context ('inside a polygon on the sea') implies when the tool is appropriate. However, it gives no explicit when-to-use or when-not-to-use guidance, and it does not route the agent among the many similarly named sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Biohotspot's research library (more than 5,200 papers and reports on coasts and marine habitats) for the words; returns titles, years and DOI links where known (10 by default, 50 at most). Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint/openWorldHint/destructiveHint, so the description's 'Read-only' restates structured data. It does add genuinely new behavior: default result count of 10, hard cap of 50, and the returned fields (title, year, DOI where known).
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?
Compact and front-loaded: corpus, search action, return shape, page limits and safety profile in essentially one sentence with a parenthetical. Slight awkwardness in 'for the words' but nothing wasted.
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, the description does its job by naming returned fields and the result-count ceiling. Remaining gaps (pagination beyond limit, result ordering/relevance, query syntax) are minor for a two-parameter search tool.
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 coverage is 0%, so the description must compensate. It fully documents the limit parameter's default (10) and maximum (50), which the schema lacks, but says only 'for the words' about query — no matching rules, phrase/boolean support, or which fields are searched.
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?
States a specific verb+resource ('Search Biohotspot's research library') plus the corpus scope (5,200+ papers on coasts and marine habitats) and what is returned (titles, years, DOI). This clearly separates it from the spatial/project siblings, though no sibling is named explicitly.
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?
Use is implied by the name and the described corpus, but there is no explicit 'use this when…' guidance, no statement of when another tool (e.g. get_marine_park, understand_area) is a better choice, and no required-parameter prerequisites called out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run the Marxan optimiser on the example project's planning data (Exmouth Gulf, Western Australia only): the cheapest set of planning squares that meets every habitat target. protect = planning-square ids always included (understand_area returns them as pus); target_pct = one target for every habitat, in %. Takes a few seconds; returns the summary, each habitat's result and the best solution. Nothing is saved to your projects.
| Name | Required | Description | Default |
|---|---|---|---|
| reps | No | Runs, 1-20 (default 5) | |
| protect | No | ||
| target_pct | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint/openWorldHint/destructiveHint, so the safety profile is covered; the description adds genuinely new behavior: runtime expectation ('takes a few seconds'), the shape of the response ('the summary, each habitat's result and the best solution'), and a persistence guarantee ('Nothing is saved to your projects'). It does not cover failure modes (e.g., invalid protect ids) or whether the run is deterministic across `reps`, which keeps it off a 5.
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?
Two sentences, front-loaded with what the tool produces before the parameter glossary. Every clause carries information — scope, output, parameter meaning, runtime, and side-effect — with no restatement of the name or 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?
For a read-only, three-parameter compute tool with no output schema, the description supplies return shape, runtime, and a no-persistence guarantee, which is nearly everything an agent needs. The remaining gap is error/edge behavior (invalid protect ids, behavior when target_pct is omitted).
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 coverage is only 33% (only `reps` is documented), so the description must carry the load — and it does, explaining that `protect` takes planning-square ids sourced from understand_area's `pus` and that `target_pct` is a single percentage applied to every habitat. The non-obvious Marxan semantics of these two params are precisely what the schema omits; only edge details like default/empty `protect` behavior are unstated.
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?
States a specific verb+resource (run the Marxan optimiser on the example project's planning data) and glosses the output in plain language: 'the cheapest set of planning squares that meets every habitat target.' The scope restriction (Exmouth Gulf, Western Australia only) makes it unmistakable against siblings like get_project or understand_area, which read data rather than run an optimiser.
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?
Establishes the applicable context clearly ('example project's planning data ... Western Australia only') and points the agent at understand_area as the source of `pus` ids for `protect`, which is real workflow routing. It stops short of an explicit when-not-to-use or a named sibling alternative for the same goal, so it is clear but not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check an area against its protection targets: which habitats it holds, how much of each, what is already protected, and how far each habitat is from its target. Give a polygon, or a point and radius_km. Outside Biohotspot's local planning data the answer comes from world maps and is marked rough: true. Read-only; nothing is saved.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | No | Latitude of the place to look at, WGS84 | |
| lon | No | Longitude of the place to look at, WGS84 | |
| polygon | No | A GeoJSON Polygon (WGS84) | |
| radius_km | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint, destructiveHint false), so the bar is lower, and the description still adds genuine behavior: outside local planning data the result falls back to world maps and is flagged rough: true. That fallback and its output marker are things the annotations cannot convey. It omits the response shape and any performance caveats, keeping it from a 5.
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?
Four tight sentences, front-loaded with the purpose and followed by input modes, data-source caveat, and safety note. No filler, though the trailing 'Read-only; nothing is saved' largely restates the readOnlyHint annotation.
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 four optional parameters, a nested polygon object, and no output schema, the description still tells the agent what comes back (habitats, amounts, protection, distance to target, rough flag) and how inputs combine. Nothing needed to call it correctly is missing.
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 coverage is 75%, and radius_km has no schema description, so the description usefully supplies the pairing rule: polygon OR point plus radius_km, which tells the agent the parameters are alternatives rather than cumulative. It does not explain units or limits on radius_km or polygon validity beyond GeoJSON/WGS84 already in the schema.
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 gives a specific verb and resource ('check an area against its protection targets') and enumerates the outcome dimensions: habitats held, amount of each, protection status, and distance from target. That is far more informative than the title alone. It stops short of naming any sibling, so an agent must infer the boundary with look_in_area or get_features on its own.
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?
'Give a polygon, or a point and radius_km' defines acceptable input shapes but not when this tool is preferable to siblings like look_in_area, look_here, or get_features. Usage context is implied by the word 'targets' rather than stated as a selection rule.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
add_project_datafind_layersget_featuresget_marine_parkget_projectlist_project_datalist_projectslook_herelook_in_areasearch_paperssimulateunderstand_areaNOAA CoastWatch — satellite and model ocean data via ERDDAP.
Ocean acoustics: propagation models, bathymetry, sound speed, vessel noise, live AIS. Open.
US IOOS — regional ocean observing data via ERDDAP.
Structured habitat data and advisory tools for aquariums, marine tanks, terrariums and paludariums.
Add one secure layer between your agents and this server.
