Skip to main content
Glama

Smartplan MCP by usefulapi

List locations

smartplan_list_locations
Read-onlyIdempotent

One page of locations for the selected account; continue with next_offset. Read-only Smartplan Pro API.

Input Schema

NameRequiredDescriptionDefault
limitNo
offsetNo
is_hiddenNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

B3.4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so 'Read-only Smartplan Pro API' adds nothing. What does earn credit is the pagination contract — one page at a time, continue with next_offset — a behavioral trait found nowhere in the annotations or schema that directly shapes the calling loop.

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?

A single compact statement, front-loaded with the resource and the continuation instruction. Nearly zero waste; the redundant 'Read-only Smartplan Pro API' clause is the only filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

It is a trivial read-only list tool with no output schema, so the return-shape burden is low, but the description never explains is_hidden, never resolves the next_offset/offset naming mismatch, and leaves the 'selected account' context unexplained — enough gaps to keep it at minimum viable.

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

Parameters2/5

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

Schema description coverage is 0%, so the description must carry parameter meaning and doesn't. It references 'next_offset', a name that does not exist in the schema (the field is 'offset'), and says nothing about limit's 1-50 cap or what is_hidden filters — both of which are unintuitive and undocumented.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('One page of locations') and scopes it to 'the selected account', which separates it from the singular smartplan_get_location. The only gap is that 'selected account' refers to an ambient context never exposed as a parameter, so the scope is slightly hand-wavy.

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

Usage Guidelines3/5

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

'continue with next_offset' implies the pagination loop, which is real usage guidance. However, it never says when to prefer this over smartplan_get_location for a known location, nor how to obtain the account context, so the guidance is implied rather than explicit.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.