Skip to main content
Glama
Sign In
SetLuca

SetLuca

Official
by setluca
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Read this period's spend

luca_usage_spend
Read-onlyIdempotent

Read model spend by agent and day for a period, compare it with the billing account's monthly budget, and check whether AI replies are paused.

Instructions

Read model spend for the period, rolled up by agent and by day, against the billing account's monthly budget, and whether AI replies have paused.

Luca operation: GET /api/usage Required scopes: usage:read Required OAuth scope: luca:read; data sensitivity: redacted Does not require idempotency. Use workspaceId or workspaceSlug to override the default workspace configured by environment.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "luca_usage_spend"
  }
}

Input Schema

NameRequiredDescriptionDefault
queryNo
workspaceIdNoOptional Luca workspace id override.
workspaceSlugNoOptional Luca workspace slug override.

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.4.2
    • addedOutput schema / properties / result / properties / cap / properties / level
      Added value: +{
+  "type": "string"
+}
    • addedOutput schema / properties / result / properties / cap / properties / windowEndsAt
      Added value: +{
+  "type": "string"
+}
  2. First observedv0.4.0

TDQS

A3.7/5.0
Behavior4/5

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

Beyond the annotations (readOnly, idempotent, non-destructive, closed-world), the description adds genuinely useful context: the underlying operation GET /api/usage, the required usage:read and luca:read scopes, and that the data is redacted. The 'Does not require idempotency' line merely restates idempotentHint and the duplicated scope wording is slightly noisy, but the auth and sensitivity disclosure is real added value.

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 purpose sentence is front-loaded and dense with the right details, and the metadata lines are short. Minor waste exists in the redundant 'Does not require idempotency' line (already covered by idempotentHint) and the overlapping 'Required scopes' / 'Required OAuth scope' pair, which could be one statement.

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 need not be described, and the auth, sensitivity, and endpoint metadata round out the operation. The remaining gap is definitional: 'this period' is never pinned down (billing month vs. rolling window) and its relationship to the since parameter is unstated, which matters for a budget-comparison tool.

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?

Schema coverage is 67%; workspaceId and workspaceSlug are already documented in the schema, and the description only restates that they override the environment default. The genuinely underspecified parameter is the nested query.since, which the schema types only as a non-empty string with no format, and the description never explains its accepted format or how it interacts with 'this period'. Baseline 3 fits: some added meaning, but the key ambiguity is left unaddressed.

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?

The first sentence names a specific verb and resource (read model spend) plus the exact rollups returned (by agent, by day), the budget comparison, and the paused-replies flag. That is far more concrete than a title restatement and is distinguishable from the analytics siblings, which deal with sales/conversation metrics rather than billing spend. It stops short of explicitly naming a sibling it is not, so it does not reach 5.

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?

Usage is only implied: an agent can infer it should call this when it needs current spend, but there is no statement of when to prefer it over an analytics or rollup sibling, nor any precondition such as requiring a configured billing account. The one guidance sentence present is about workspace overriding, which is parameter behavior rather than tool selection.

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

Deploy Server

Other Tools