Skip to main content
Glama

Moxlade — Upwork buyer intelligence

by com.moxlade

Your plan, caps and usage

get_plan
Read-onlyIdempotent

What this token is allowed to do right now, and what it costs.

Call it when another tool refuses, when you want to know how long a trial has left, or before telling a person they need to pay. It takes no arguments — it describes the token you are already authenticated with.

Returns the plan, its state (trial / active / expired), the flat monthly price, whether saved searches are currently matching, the subscribe and cancel links, and usage — today's call count against the daily cap, today's distinct corpus questions against theirs, and when both reset. Read usage before a long paging walk: every page is one call.

trial_ends_at is a date only while the state IS trial, and null otherwise. A paid plan keeps the date internally so that cancelling inside the original window falls back to the trial, but showing it on an active subscription made the plan look like it was expiring.

Readable on every plan state including expired, deliberately: someone deciding whether to pay has to be able to see what they had.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
planNoThe plan on this account.
labelNoThe token's label, which carries the source it was minted from. Null for a token minted by hand before self-serve. A null label means the source is unknown, not that the signup was direct.
stateNotrial | active | expired. This is what the corpus tools gate on.
usageNoToday's counters. NULL when they could not be read — never zeros, which a caller would budget against.
billingNoHow billing works, in one sentence.
subscribeNoWhere to start paying, when a link is configured.
trial_ends_atNoISO 8601 while the state IS trial, and null otherwise. A paid plan keeps the date internally but does not report it.
saved_searchesNoWhether saved searches are currently matching or paused.
price_usd_monthNoThe flat monthly price. No credits and no per-call fee.
manage_or_cancelNoWhere to change or cancel the subscription.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already mark this as read-only and idempotent, and the description adds substantial behavioral detail beyond that: trial_ends_at is null unless state is trial, paid plans keep the trial date internally, usage counts each paging call, and the tool intentionally remains readable on expired plans. These details help an agent reason about edge cases without contradicting 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?

Although the description is longer than average, every sentence earns its place: the opening summarizes purpose, the middle gives invocation triggers and return fields, and the later paragraphs explain important field semantics and design rationale. It is front-loaded and well structured with no filler.

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

Completeness5/5

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

For a zero-argument tool with an output schema, the description is complete: it covers when to call, what fields come back, how usage behaves, trial-specific edge cases, and accessibility across all plan states. An agent has everything it needs to decide when to invoke the tool and interpret the result.

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

Parameters5/5

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

There are zero parameters, so the baseline is 4. The description adds meaning by explicitly saying the tool takes no arguments and clarifying that it operates on the token the agent is already authenticated with. This resolves any ambiguity about how the tool knows whose plan to return.

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 clearly states that get_plan returns what the current authenticated token is allowed to do, its plan state, caps, and usage. It uses specific verbs like 'describes' and 'returns' and distinguishes this tool from siblings by focusing on plan/cost/auth context. The first sentence alone is a precise, non-tautological purpose statement.

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 gives explicit scenarios for when to call it: when another tool refuses, when checking trial time, or before asking someone to pay. It does not name alternative tools or provide when-not-to-use guidance, but the sibling list contains no obvious overlap, so the context is clear enough.

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

All Moxlade — Upwork buyer intelligence 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.6/5.0
Disambiguation5/5

Each tool maps to a distinct resource or action: search, filter validation, saved-search management, buyer lookup, buyer quality, job scoring, market rates, and account/plan introspection. The get_* tools are cleanly separated by complements such as get_job vs get_job_score and get_buyer vs get_buyer_quality, so an agent should not struggle to pick the right one.

Naming Consistency5/5

All tool names consistently use snake_case verb_noun or verb_adjective_noun patterns, such as search_jobs, check_prefilter, delete_saved_search, and get_buyer_quality. There are no camelCase names, vague verb-only names, or mixed conventions.

Tool Count5/5

At 15 tools, the server sits exactly within the ideal range and each tool earns its place in the workflow. The set covers discovery, enrichment, saved-search lifecycle, and account introspection without obvious redundancy.

Completeness4/5

The core workflow is well covered: search, prefilter validation, job detail, scoring, buyer identity, payment quality, saved-search create/list/delete, and plan/activity visibility. The main gap is the lack of an update operation for an existing saved search, such as changing its filter or attaching a webhook later; this is a minor workaround rather than a blocking dead end.

Resources