Skip to main content
Glama
mizcausevic-dev

mcp-kinetic-gain

by mizcausevic-dev
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

defensetech_check_dfars_72h_clock

Calculate the DFARS 252.204-7012 discovery-to-filing 72-hour interval from supplied timezone-qualified timestamps. Requires discovered_at, not occurred_at.

Instructions

Calculate the DFARS 252.204-7012 discovery-to-filing 72-hour interval from supplied timezone-qualified timestamps. Requires discovered_at, not occurred_at. Invalid or pre-discovery filing timestamps return valid=false and within_window=false. This arithmetic preview does not establish a reporting duty or prove filing.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
filed_atYes
discovered_atYesWhen the cyber incident was discovered; the reporting clock starts here.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • addedInput schema / properties / discovered_at
      Added value: +{
+  "description": "When the cyber incident was discovered; the reporting clock starts here.",
+  "format": "date-time",
+  "type": "string"
+}
    • removedInput schema / properties / occurred_at
      Removed value: -{
-  "format": "date-time",
-  "type": "string"
-}
    • changedInput schema / required
      Previous value: -[
-  "occurred_at",
-  "filed_at"
-]New value: +[
+  "discovered_at",
+  "filed_at"
+]
  2. First observedv0.9.0

TDQS

A3.8/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does disclose concrete behavior: invalid or pre-discovery filing timestamps return valid=false and within_window=false, and the tool is framed as an arithmetic preview without legal effect. It does not describe the shape of the successful return or the exact fields of the interval result.

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?

Four tight sentences, front-loaded with the computation, then the input constraint, then negative-case behavior, then the disclaimer. Every sentence carries information and nothing is padded, though the final disclaimer could be folded in.

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?

There is no output schema and no annotations, so the description is the only source of behavioral truth. It covers negative-case returns and legal scope but omits the success-case return payload and leaves one of two required parameters undocumented, so it is only partially complete for a computation tool of this importance.

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 50%: discovered_at is documented in the schema, but filed_at only carries a date-time format. The description partly compensates by emphasizing 'timezone-qualified timestamps' and distinguishing discovered_at from occurred_at, but leaves filed_at semantics to inference, so this sits at the baseline.

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 ('Calculate') and resource ('the DFARS 252.204-7012 discovery-to-filing 72-hour interval'), so the operation is unambiguous. No sibling tool overlaps this computation, and the domain-specific reference (DFARS 252.204-7012) makes the scope precise.

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 a real input-routing rule ('Requires discovered_at, not occurred_at') and a scope disclaimer ('does not establish a reporting duty or prove filing'), which implies when it is and isn't the right call. But it never states when to use this versus alternatives or prerequisite conditions in an explicit when/when-not form.

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