Skip to main content
Glama
Sign In
Free Codin Agent

Free Codin Agent

by office233
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

resource_status

Read-onlyIdempotent

Inspect current workstation resource pressure and available admission-controller slots to plan whether builds, tests, LSP, or background jobs can start now.

Instructions

Current workstation resource pressure and admission-controller slots for commands, builds/tests, LSP, diagnostics, background processes and video work.

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": "resource_status"
  }
}

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.0

TDQS

A3.5/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false. The description adds useful scope by naming the resource categories it covers, but it does not disclose freshness guarantees, latency, or whether the values are cached or live beyond the word "Current".

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?

A single tightly written sentence that front-loads the resource being reported and then enumerates the categories. No redundancy or filler.

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?

For a zero-parameter status tool with rich annotations, the description is nearly complete. It identifies what is reported but does not describe the shape or fields of the return value, which would be useful since no output schema exists.

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

Parameters4/5

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

The tool takes zero parameters, so there are no parameter semantics to clarify. The baseline for a 0-parameter tool is 4, and the description adds no confusion.

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 description clearly states what the tool returns: current workstation resource pressure and admission-controller slots across specific work categories. It lacks any explicit differentiation from siblings such as get_system_info or lsp_status, which keeps it from a 5.

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

Usage Guidelines2/5

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

It does not say when to use this tool, when not to use it, or what alternatives exist. The reader must infer that it is for checking resource status before starting heavy work, but no guidance is provided.

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