Skip to main content
Glama
Sign In

goldseam

by com.ksaworks
OverviewDiscussionsAdmin

CourseShelf Performance

get_courseshelf_performance
Read-only

How did calls to the CourseShelf box perform? From the box's call log: each call that reached the box, newest first, with its time (at), tool, outcome (answered; stopped by a budget; busy, queue full or wait expired; invalid_params; error; not_pinned), ms from the slot being taken to the answer, the build that answered, and the stated cause where there is one; per tool, the count of each outcome; and the log files read. Also returns effective INI settings and the pinned database's page size, page count and free-list pages. Request storage_details for the largest table/index objects from SQLite dbstat, within the query budget. These are storage measures, not compaction-savings estimates or RAM measurements. Arguments are logged for the catalog services only. An empty log window is said so.

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

Input Schema

NameRequiredDescriptionDefault
toNoOptional ISO time the window ends (default now)
fromNoOptional ISO time the window starts (default 24 hours before 'to')
toolNoOptional: only the calls of this tool
limitNoOptional call page size (default 200); also limits storage objects to at most the default page size. The answer-size budget may trim either list further and says so
min_msNoOptional: only the calls that took at least this many ms
outcomeNoOptional: only the calls with this outcome
storage_detailsNoOptional, default false: read the largest table/index objects from SQLite dbstat, showing allocated, payload and unused-within-pages bytes. This can scan the artifact; it runs only on request under the existing query budget. An unavailable breakdown is stated, never reported as zero.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / limit / description
      Previous value: -"Optional page size (default 200); the answer-size budget may trim it further and says so"New value: +"Optional call page size (default 200); also limits storage objects to at most the default page size. The answer-size budget may trim either list further and says so"
    • addedInput schema / properties / storage_details
      Added value: +{
+  "description": "Optional, default false: read the largest table/index objects from SQLite dbstat, showing allocated, payload and unused-within-pages bytes. This can scan the artifact; it runs only on request under the existing query budget. An unavailable breakdown is stated, never reported as zero.",
+  "type": "boolean"
+}
  2. Added

TDQS

A3.6/5.0
Behavior4/5

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

Annotations only declare readOnlyHint=true, so the description carries the rest and does so well: answer-size budget may trim lists and says so, storage_details can scan the artifact, unavailable breakdowns are stated rather than reported as zero, and arguments are logged only for catalog services. What it omits is what the INI settings / page metrics are scoped to (instance-wide vs pinned artifact), which matters for a diagnostic tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

It opens with the useful framing and puts the return contents up front. But the body is a single dense run-on paragraph where multi-clause outcome definitions ('busy, queue full or wait expired') and caveats about storage measures vs compaction/RAM are jammed together, making it harder to scan than its length warrants.

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 no output schema, the description does the necessary work of describing the return shape in detail, including the outcome vocabulary and the fact that an empty window is reported explicitly. The remaining gap is scope ambiguity relative to the sibling summary tool, not missing return-value information.

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 description coverage is 100%, and the schema already documents defaults for from/to/limit/min_ms/outcome/storage_details, so the baseline applies. The description adds marginal value, chiefly that limit constrains both the call page and the storage-object list and that the budget may further trim either, but that fact is essentially restated from the schema.

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 resource and enumerates exactly what comes back: per-call log rows (time, tool, outcome, ms, build, cause), per-tool outcome counts, log files read, effective INI settings, and pinned DB page size/count/free-list. That is far more than a restatement of the name. It does not distinguish itself from the sibling get_courseshelf_summary, so an agent must guess which of the two to open for a quick overview.

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?

Gives conditional guidance for one parameter ('Request storage_details for the largest table/index objects ... runs only on request under the existing query budget') and notes empty-window behavior, which is useful. But it never says when to use this versus get_courseshelf_summary, nor which questions this tool answers that the summary does not.

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

All goldseam 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