Systemores Cloud MCP Server

Measure Cognitive Throughput Drag

systemores_measure_drag

Read-onlyIdempotent

Measures operational latency, response length, and execution drag to assess cognitive throughput stability and detect performance drift in agent workflows.

Instructions

Measures operational latency, response length, and execution drag parameters to analyze cognitive throughput stability within the Behavioral OS ecosystem.

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": {
      "promptLength": "<promptLength>",
      "responseLength": "<responseLength>",
      "latencyMs": "<latencyMs>"
    },
    "name": "systemores_measure_drag"
  }
}

Input Schema

Name	Required	Description
`latencyMs`	Yes	The end-to-end response latency in milliseconds. Must be >= 1.
`promptLength`	Yes	The character length of the prompt sent to the agent.
`responseLength`	Yes	The character length of the agent's response.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.1.3Nov 12, 2026

TDQS

C2.6/5.0

Behavior2/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds nothing behavioral beyond that: it doesn't say whether results are persisted, how thresholds are interpreted, or what a 'drag' outcome implies. It largely restates the measurement subject rather than disclosing behavior.

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 is a single front-loaded sentence with no wasted clauses, but the trailing "within the Behavioral OS ecosystem" is pure filler and the sentence commits to jargon instead of specificity. Brevity here reflects under-specification rather than discipline.

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

Completeness3/5

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

Inputs are fully covered by schema and the operation is a safe, idempotent read, so the essentials are present. However, with no output schema there is no explanation of what the returned drag/throughput metrics look like or how to interpret them, which is the main missing piece for a measurement 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 description coverage is 100%, so all three parameters (latencyMs, promptLength, responseLength) are already fully documented with types and minimums. The description names latency and response length but adds no unit, aggregation, or relationship semantics beyond the schema, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The verb "Measures" is concrete and the object lists latency and response length, which map onto real inputs. But the key concept "execution drag" and "cognitive throughput stability" are undefined jargon, and nothing distinguishes this from siblings such as systemores_evaluate_drift or systemores_audit_turn_live that also sound like measurement tools.

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?

There is no statement of when to call this versus alternatives, no preconditions (e.g., that latency and lengths must come from a completed turn), and no exclusions. The agent must guess how this differs from the many other audit/measure siblings.

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

Deploy Server