Skip to main content
Glama
Sign In

Mencoro

by com.mencoro
OverviewDiscussionsAdmin

Get plan and usage

get_usage
Read-onlyIdempotent

An organization's subscription, how many tracked queries its projects the caller can access have, and how many checks they are projected to run per month. Plan entitlements (tracked-query and check limits) are included for owners only, as in the web app; for other members "entitlements" is null. For a member restricted to selected projects, the plan, billing cycle, check budget, consumption and deactivation reason in "subscription" are null too. Use it before creating tracked queries or raising check frequency, to stay within the plan.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "organizationId": "<organizationId>"
    },
    "name": "get_usage"
  }
}

Input Schema

NameRequiredDescriptionDefault
organizationIdYes

Output Schema

NameRequiredDescriptionDefault
entitlementsYesNull unless the caller owns the organization.
subscriptionYesThe current subscription contract of an organization. For a member restricted to selected projects, the plan, the billing cycle, the check budget, its consumption and the deactivation reason are null.
trackedQueriesYesHow many tracked queries an organization has configured
projectedMonthlyChecksYesWhat an organization's current tracking configuration would consume in a month

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedOutput schema / properties / subscription / description
      Previous value: -"The current subscription contract of an organization"New value: +"The current subscription contract of an organization. For a member restricted to selected projects, the plan, the billing cycle, the check budget, its consumption and the deactivation reason are null."
    • changedOutput schema / properties / subscription / properties / deactivationReason / description
      Previous value: -"Why the subscription is currently inactive. Null for an active subscription, and meaningless once \"cancelledAt\" is set - the cancellation supersedes it."New value: +"Why the subscription is currently inactive. Null for an active subscription and for a member restricted to selected projects, and meaningless once \"cancelledAt\" is set - the cancellation supersedes it."
  2. Changed2 schema fields changed
    • changedOutput schema / properties / projectedMonthlyChecks / properties / activeTrackedQueryCount / description
      Previous value: -"Active tracked queries the projection was summed over, across every project of the organization, archived projects included. Paused queries are excluded from both figures. Never null."New value: +"Active tracked queries the projection was summed over, across every project of the organization the caller can access, archived projects included. Paused queries are excluded from both figures. Never null."
    • changedOutput schema / properties / trackedQueries / properties / trackedQueryCount / description
      Previous value: -"Tracked queries across every project of the organization, archived projects included, counting active and paused queries alike. Never null; 0 means none are configured."New value: +"Tracked queries across every project of the organization the caller can access, archived projects included, counting active and paused queries alike. Never null; 0 means none are configured."
  3. Changed1 schema field changed
    • changedOutput schema / properties / projectedMonthlyChecks / properties / projectedMonthlyChecks / description
      Previous value: -"Checks a month of the current configuration would consume: for each ACTIVE tracked query, its runs per month (daily 30, weekly 4, monthly 1) multiplied by its nPasses, summed. Never null."New value: +"Checks a month of the current configuration would consume: for each ACTIVE tracked query, its runs per month (daily 30, weekly 4, monthly 1) multiplied by its nPasses and engine weight, summed. Claude uses five checks per pass; every other engine uses one. Never null."
  4. Added

TDQS

A4.1/5.0
Behavior4/5

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

Discloses behavior the annotations do not: entitlements are null for non-owners, and for project-restricted members the plan, billing cycle, check budget, consumption, and deactivation reason are null. That null-field semantics is exactly the kind of context an agent needs to interpret results, though it doesn't mention any rate limits or staleness/caching behavior.

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?

Front-loads the primary payload and follows with the permission/null caveats and usage guidance in a logical order. The second sentence is somewhat dense with conditional clauses, but every sentence carries information.

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?

An output schema exists, so return-shape explanation isn't required, yet the description still explains visibility gating on returned fields, which is complete enough for correct invocation and interpretation. The main residual gap is the organizationId parameter's semantics.

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

Parameters3/5

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

There is one parameter with 0% schema description coverage, so the description should compensate but barely does — organizationId is only implied by 'An organization's subscription.' It gives no format or sourcing guidance for the ID, so the agent must infer it.

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?

States a specific verb+resource: an organization's subscription, tracked-query counts, and projected monthly checks. It is clearly distinguishable from siblings like get_organization or get_organization_overview because it scopes to plan entitlements and consumption rather than profile/overview data.

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?

Gives explicit usage timing: call it before creating tracked queries or raising check frequency to stay within the plan. It does not name an alternative tool or a when-not-to-use condition, but the context is concrete enough for an agent to act on.

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

All Mencoro toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources