Skip to main content
Glama
SujayGG

pf-debate-mcp

by SujayGG
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

cut_card

Cut verbatim evidence cards from source text, ensuring exact quotes with highlights and underlines. Rejects fabricated text and provides hints for mismatches.

Instructions

Cut an evidence card. The body is the exact source text from start_quote through end_quote (a few sentences to a few paragraphs; enough context that the author's meaning is clear). highlight = phrases read aloud; underline = wider phrases that give context (defaults to highlight). Every quote must be copied verbatim from the source (only whitespace, quote marks and dashes are normalized); anything else is rejected with a hint showing where the text stopped matching. source_id: sN from fetch_source, or a card id (cN, lib:N) to re-cut an existing card. paragraph: the [N] number from fetch_source where the card starts; required when start_quote appears more than once in the source.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tagYes
urlYes
dateYes
qualsYes
titleYes
authorYes
end_quoteYes
highlightYes
paragraphNo
publisherYes
source_idYes
underlineNo
start_quoteYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.3.0
    • addedInput schema / properties / paragraph
      Added value: +{
+  "anyOf": [
+    {
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Paragraph"
+}
  2. First observedv0.2.1

TDQS

A4.1/5.0
Behavior4/5

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

With no annotations, the description carries the behavioral burden. It explicitly discloses that quotes must be verbatim, which characters are normalized, that mismatches are rejected with a hint, and how highlight/underline defaulting works. It doesn't describe side effects of re-cutting an existing card, but the core validation behavior is transparent.

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 description is a single dense paragraph with no wasted sentences; every rule earns its place. It could be improved with structured parameter formatting, but it remains readable and front-loads the most important semantic definition of the body quote.

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

Completeness4/5

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

For a 13-parameter tool with no annotations and an output schema present, the description covers the critical selection, validation, and re-cutting behavior. It is missing definitions for some required metadata fields, but the agent has enough to invoke the tool correctly in the main workflow.

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 0%, so the description must compensate. It does explain start_quote, end_quote, highlight, underline, source_id, and paragraph well. However, it leaves several required parameters—especially tag and quals—undefined, forcing the agent to infer their meaning from names alone.

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 specific action ('Cut an evidence card') and defines what that means: preserving exact source text from start_quote to end_quote. It clearly differentiates this from sibling tools like fetch_source, search_cards, and get_card by describing a card-creation/recutting operation.

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 concrete usage context: source_id comes from fetch_source, and a card id (cN, lib:N) can be used to re-cut an existing card. It does not explicitly say 'use this instead of search_cards/get_card', but the intended workflow and alternatives are reasonably clear from context.

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