Skip to main content
Glama
Sign In

WritersLogic business agents

by com.writerslogic.agents
OverviewDiscussionsAdmin

document-supersession

Is this document still current, or superseded by a newer one? — Given the target document id, the supplied set of documents (id, effective date, which ids each one supersedes, withdrawn flag) and a reference date, reports whether the target is superseded or withdrawn as of that date, following supersession chains, and names the superseding document and its date. For an agent about to rely on a standard, price list, policy or datasheet revision. It can only see

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": {
      "target": "<target>",
      "documents": "<documents>",
      "asOf": "<asOf>"
    },
    "name": "document-supersession"
  }
}

Input Schema

NameRequiredDescriptionDefault
asOfYesReference date: a superseding document counts only if effective on or before it.
targetYesId of the document being relied on.
documentsYesThe documents the caller knows of, including the target.
listCompleteNoThe caller asserts documents holds every document that could supersede the target. Required for a pass.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

B3.1/5.0
Behavior3/5

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

With no annotations, the description carries the full burden, and it does disclose real mechanics: supersession chains are traversed, the reference date gates which superseding documents count, and the result names the superseding document and date. But it never states what happens when the document set is incomplete, and the truncation ('It can only see') severs exactly the limitation disclosure the schema's listComplete parameter implies is central to the tool's reliability.

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

Conciseness2/5

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

The question-then-given-clause structure is sound and mostly front-loaded, but the description terminates mid-sentence, which is a concrete structural defect rather than a stylistic nit. A dangling clause wastes the reader's attention and signals the definition was not finished.

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?

There is no output schema and no annotations, so the description must carry return meaning and safety profile itself; it partially does (names the superseding document and date). But for a tool whose answer may be a falsely reassuring 'still current' when documents are missing, the unstated completeness caveat is the single most important thing an agent needs, and the truncated final sentence drops it.

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 the baseline is 3 and the schema already explains asOf, target, documents, and listComplete. The description summarizes the document record shape (id, effective date, supersedes, withdrawn flag) but adds no interpretation beyond the schema, and it does not explain listComplete at all — that sentence is the one that got cut.

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?

The description names a concrete decision verb and resource: it reports whether the target document is superseded or withdrawn as of a date, follows supersession chains, and names the superseding document. That is far more specific than a restatement of the name. It loses a point because the closing sentence is truncated mid-thought ('It can only see'), leaving the scope statement unfinished rather than crisp.

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?

It supplies a clear situational trigger — 'For an agent about to rely on a standard, price list, policy or datasheet revision' — which tells the agent when this is the right call. However, it names no alternative or fallback for the case where the caller does not know the document set, and the one exclusion-like caveat that was being stated is cut off, so the when-not guidance is absent.

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