Screwtape.ai

Try one sample duplicate-invoice check (free, no key)

try_check

Read-onlyIdempotent

See what a spend check returns before you have a key. Runs ONE sample check on a fixed demo invoice: a duplicate match against an invoice paid earlier, required fields, and a sum check that the line items add up to the total. Call it once to learn the response shape. Do NOT call it on your own invoices (it ignores them; use check_duplicate_invoice) or in a loop: it is limited to 5 calls per hour per IP and per MCP session. Inputs: scenario (optional: duplicate, the default, clean, or bad_total). Returns: demo, scenario, invoice, earlier_invoice, duplicate.status (unique or duplicate), checks, next_step.action (pass, retry or escalate), note, next_action and request_id. No receipt and nothing is stored. Cost: free. Needs no key.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "try_check"
  }
}

Input Schema

Name	Required	Description	Default
`scenario`	No	Which fixed demo invoice to check: duplicate (default; the same invoice sent again with a reformatted id), clean, or bad_total (the line items do not add up).

Output Schema

Name	Required	Description	Default
`demo`	Yes
`note`	Yes
`checks`	Yes
`invoice`	Yes
`scenario`	Yes
`duplicate`	Yes
`next_step`	Yes
`request_id`	Yes
`next_action`	Yes
`earlier_invoice`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 5, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, and the description still adds substantial context: 5 calls per hour per IP and per MCP session, no receipt generated, nothing stored, free of charge, and no API key needed. It also enumerates the response fields and the possible next_step actions, which is behavior an agent cannot infer from the hints.

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?

Front-loaded with the value proposition and the constraint, then the inputs and outputs. It is dense but readable; the long enumeration of return fields is somewhat redundant given an output schema exists, costing a little tightness.

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

Completeness5/5

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

For a free, keyless demo tool the description covers purpose, exclusions, rate limits, cost, storage behavior, and expected output. Nothing an agent needs in order to call it correctly once and interpret the result is missing.

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 100% and the enum values are already documented with their meanings in the schema, so the description's scenario parenthetical largely restates structured data. It does confirm that duplicate is the default, which is a small addition beyond the schema, but nothing about format or interaction between values.

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 concrete verb and resource: runs ONE sample duplicate-invoice check against a fixed demo invoice, covering duplicate match, required fields, and line-item sum. It explicitly separates itself from check_duplicate_invoice, so an agent can pick between them without opening either schema.

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

Usage Guidelines5/5

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

Gives explicit when (call once to learn the response shape), explicit when-not (do not run on your own invoices, do not loop), and names the correct alternative (check_duplicate_invoice). The rate limit is cited as the reason for the no-loop rule, which makes the guidance actionable.

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

All Screwtape.ai 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?