WritersLogic business agents

requirement-coverage

Checklist coverage: caller requirements against caller evidence — Evaluates a checklist of requirements the caller defines (each made of needs on evidence keys: present, equals, one of, min/max, maximum age) against evidence the caller supplies, and returns met / unmet / unknown per requirement with the exact need and value that decided it. For an agent that must prove a task's acceptance criteria were covered before it reports done. Does not judge whether the p

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": {
      "requirements": "<requirements>",
      "evidence": "<evidence>"
    },
    "name": "requirement-coverage"
  }
}

Input Schema

Name	Required	Description
`asOf`	No	Reference instant (ISO date or instant) for evidence age; required only when a need sets maxAgeDays. The check never reads the clock.
`evidence`	Yes	Observed facts. Several items may share a key (conflicts surface as unknown).
`requirements`	Yes	The checklist.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 15, 2026

TDQS

A4.2/5.0

Behavior4/5

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

With no annotations supplied, the description carries the full load and does disclose meaningful behavior: it returns met/unmet/unknown with the deciding need and value ('witness'), i.e. it is explanatory rather than a bare boolean. It stops short of stating that evaluation is pure/side-effect-free and says nothing about the 100-requirement / 500-evidence caps, so the disclosure is useful but not exhaustive.

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?

The purpose is front-loaded in a short lead phrase, followed by a dense but informative sentence, and every clause carries information. However the text ends mid-sentence ('whether the p'), leaving a dangling fragment that wastes the final slot that should have carried the boundary condition.

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 must cover return shape and behavior — it does explain met/unmet/unknown plus witnesses, and mentions conflicts surfacing as unknown only in the schema. The truncated final clause means the stated scope boundary is incomplete, which is a real gap for a verdict-producing tool an agent will rely on before declaring done.

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?

Schema coverage is 100%, so the baseline is 3, but the description adds real context by summarizing the need vocabulary (present, equals, one of, min/max, maximum age) and framing requirements as caller-defined checklists over evidence keys. That helps an agent understand the requirements/evidence relationship beyond the per-field schema text.

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 opens with a specific verb and resource — 'Checklist coverage: caller requirements against caller evidence' — then states precisely what it evaluates (a caller-defined checklist of needs over evidence keys) and what it returns (met/unmet/unknown per requirement). This clearly separates it from domain-specific sibling coverage tools such as bid-coverage or font-coverage.

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

Usage Guidelines4/5

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

It gives an explicit when-to-use trigger: 'For an agent that must prove a task's acceptance criteria were covered before it reports done.' The beginning of a when-not boundary appears ('Does not judge whether the p...'), but no named alternative tool is offered and the exclusion is cut off, so the guidance is clear but incomplete.

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

All WritersLogic business agents tools Inspect

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

Need Help?