Skip to main content
Glama
Sign In
finance-engines-mcp

finance-engines-mcp

by Cubiczan
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Evaluate covenants

evaluate_covenants

Evaluate metric values against covenant thresholds to determine compliance and headroom, providing a compliant flag for each check.

Instructions

Test computed metrics against covenant thresholds. Each result reports the metric value, operator, threshold, compliant flag, and percentage headroom to the threshold.

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": {
      "metrics": "<metrics>"
    },
    "name": "evaluate_covenants"
  }
}

Input Schema

NameRequiredDescriptionDefault
configNoCovenant config (account_map, annual_debt_service, covenants). Defaults to the bundled sample config.
metricsYesMetric values, as from compute_covenant_metrics.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.4/5.0
Behavior2/5

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

With no annotations, the description must disclose behavioral traits. It states that it tests and reports, implying a read-like operation, but it does not mention whether it has side effects, requires specific permissions, or how it handles invalid metrics or missing config. The default config behavior is left to the schema, and the description offers no additional context about safety or edge cases.

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?

The description is a single, well-structured sentence that front-loads the core action and then lists the output fields. There is no filler or redundancy, and every word contributes to understanding the tool's function.

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

Completeness2/5

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

The tool involves nested objects, optional config, and a meaningful output format, but the description is minimal. It does not explain the prerequisite relationship with compute_covenant_metrics, how to construct the metrics object, or what happens when config is omitted. With no output schema and no annotations, the description leaves significant gaps for an agent to call it correctly.

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% for both parameters, so the schema already documents 'config' and 'metrics'. The description adds no further meaning about parameter structure or usage beyond the schema's descriptions. It mentions 'computed metrics' which aligns with the metrics parameter, but no new details are provided, so a baseline 3 is appropriate.

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?

The description states a clear verb ('Test') and a specific resource ('computed metrics against covenant thresholds'), and even enumerates the result fields. It is distinct from sibling tools like compute_covenant_metrics (which computes metrics) and compliance_certificate (which likely generates a certificate), so an agent can immediately understand its role.

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?

The description implies the tool is used after computing metrics (via 'computed metrics') but does not explicitly state when to choose it over compute_covenant_metrics or compliance_certificate. No exclusions or alternative conditions are given, so the agent must infer the usage context from sibling names.

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