Score text 0-100 for signs of AI writing, with plain reasons; strip machine typography.
Scored across 5 tools
Each tool has a distinct target: check_ai_image reads image provenance metadata, find_hidden_instructions detects prompt-injection text in images, scan_text scores local text, scan_url scores fetched web content, and cleanup_text normalizes typography. The two image tools could be momentarily confused since both inspect image metadata, and scan_url largely wraps scan_text, but the descriptions clearly differentiate them.
All names are snake_case and follow a verb_noun-like pattern (check_ai_image, cleanup_text, find_hidden_instructions, scan_text, scan_url). The verb choice varies (check vs scan vs find) which is mostly justified by differing actions, but 'check' and 'scan' on image inputs are close enough to feel slightly inconsistent.
Five tools is well-scoped for a focused AI-content detection service, with no filler or redundant entries — each tool covers a distinct input type or operation.
Covers the core detection surface: text scanning, URL/document scanning, image metadata inspection, hidden-instruction detection, and text cleanup. Minor gaps exist for non-metadata image analysis (pixel-level AI detection) and batch/multi-item scanning, but core workflows are supported.
Read what an image file declares about AI: Content Credentials (C2PA), IPTC source type, creator tool, embedded prompts. Pass image_url (https) or image_base64, not both.Signal, not a verdict: only what the file claims about itself, easy to strip or fake. Never accuse anyone on this alone.
| Name | Required | Description | Default |
|---|---|---|---|
| image_url | No | Full https:// address of the image (PNG, JPEG, GIF, WebP, TIFF, BMP) | |
| mime_type | No | Optional image type, e.g. image/png; the file's bytes decide | |
| image_base64 | No | The image as base64 (data: prefix OK); for large images use image_url |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does meaningful work: it discloses that only self-declared claims are read and that those claims are 'easy to strip or fake,' setting reliability expectations. It omits operational traits like auth requirements, rate limits, or what a null/empty result looks like.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, front-loaded with the core action and payload, followed by input selection and the interpretative caveat. Every sentence contributes; there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-parameter, zero-required, no-output-schema tool, the description effectively describes the return payload (the enumerated signal types) and the input constraint, so an agent can call it correctly. It could still note the response shape when no metadata is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 description adds the non-obvious mutual-exclusion rule ('image_url ... or image_base64, not both') that the schema itself does not state. That is genuine added value beyond the structured fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb (Read/check), a specific resource (an image file's own metadata), and enumerates exactly what is extracted: C2PA Content Credentials, IPTC source type, creator tool, embedded prompts. The image-file scope inherently separates it from the text/URL siblings (scan_text, scan_url, find_hidden_instructions).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear operating guidance — 'Pass image_url (https) or image_base64, not both' — and frames how to act on the result ('Signal, not a verdict... Never accuse anyone on this alone'). It does not, however, explicitly route the agent to or away from a sibling tool, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Strip machine typography from text without rewriting a word: smart quotes, em dashes and the rare glyphs AI models overuse become plain keyboard characters. Returns the cleaned text. It does not rewrite your words and will not make text read less AI.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | The text to clean |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does real work: it declares the operation is character-level normalization, that it preserves wording, that it returns the cleaned text, and that it will not defeat AI detection. It omits idempotency and how whitespace/formatting is handled, but the scope boundaries are unusually explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core action and sized appropriately for a one-parameter tool. The second and third sentences restate the same no-rewrite guarantee ('without rewriting a word' / 'it does not rewrite your words'), which is minor redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-string transform with no output schema, the description covers the operation, the return value, and the guarantees, which is nearly everything an agent needs. Only edge behavior (idempotency, handling of already-clean or mixed-encoding input) is left unstated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a single documented 'text' parameter, so the baseline is 3. The enumeration of character classes adds some semantic flavor about what the transform touches, but every parameter is already explained in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (strip) and resource (machine typography) and enumerates concrete targets: smart quotes, em dashes, rare overused glyphs. It clearly contrasts with the scan-oriented siblings by being a transformation, though it never names or routes against them explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied (you have text with machine typography and want plain characters), and the description draws a useful boundary that it will not rewrite words or lower AI-detection scores. However, it gives no explicit when-to-use vs. the sibling scanning tools or prerequisites, leaving routing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Score a text 0-100 for signs of AI/machine writing, with the band (low/moderate/elevated/high) and the reasons by name, each with the writer's own words behind it where there are some. Set deep=true for the most thorough read (slower, quota-limited). If the text is in a language the scanner cannot read yet, it gets no score and the answer says why. Signal, not a verdict: scores estimate how strongly text shows measurable machine-writing patterns and can be wrong in both directions. Never use a score alone to accuse a person.
| Name | Required | Description | Default |
|---|---|---|---|
| deep | No | Run the deep model for the most accurate read | |
| lang | No | Language to write the reasons in, as a code such as es; leave it out for English | |
| text | Yes | The text to score (60+ words for a reliable read) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does substantial work: it discloses that deep is slower and quota-limited, that unreadable languages yield no score with a stated reason, and that scores are estimates that can err in both directions. It omits permission/auth requirements, but failure modes and cost tradeoffs are well covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The core capability and output shape are front-loaded in the first sentence, followed by parameter guidance and caveats. It is somewhat dense and the closing ethical sentences are more advisory than operational, but nothing is redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description must explain return values — and it does: numeric score, band, named reasons with supporting quotes, plus the no-score case. Combined with the deep/lang guidance, an agent has everything needed to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3, but the description adds real meaning: deep is not just 'more accurate' but slower and quota-limited, and the reasons are written in the lang language. That context about the cost/benefit of deep goes beyond the schema's terse wording.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource — score text 0-100 for machine-writing signs — and specifies the exact output shape (score, band, named reasons with quoted evidence). It is clearly distinguishable from siblings like check_ai_image and scan_url, which handle images and URLs rather than raw text.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit conditional guidance: set deep=true for the most thorough read, and unsupported languages return no score with an explanation. It does not, however, route the agent to alternatives (e.g. scan_url for a URL, cleanup_text for rewriting), so sibling selection is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the text of a public web page (an https:// address) and score it 0-100 for signs of AI/machine writing, exactly as scan_text does: the score, the band (low/moderate/elevated/high) and the reasons by name. A reason lists the page's matched words only when they are known stock phrases, quoted from the page. The answer says which address was read and how many words it had. Web pages, plain text and PDF files can be read; private, local or internal addresses cannot. Set deep=true for the most thorough read (slower, quota-limited). Signal, not a verdict: scores estimate how strongly text shows measurable machine-writing patterns and can be wrong in both directions. Never use a score alone to accuse a person.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The full https:// address of a public web page | |
| deep | No | Use the most thorough read (slower, quota-limited) | |
| lang | No | Language to write the reasons in, as a code such as es; leave it out for English |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so: it discloses latency/quota cost of deep reads, what gets quoted and why, accuracy caveats ('signal, not a verdict', 'can be wrong in both directions'), and an ethical guardrail against using scores to accuse. This is well beyond the minimum.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Long but front-loaded and dense with earned content – scope, behavior, limits, caveats each appear once. Slightly heavy for a 3-parameter tool, but no filler sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, and the description compensates by describing the return (score, band, reasons by name, address read, word count) plus the readable formats. An agent has everything needed to call and interpret this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so all three parameters are already documented. The description only echoes deep=true's slowness/quota cost and never mentions lang, so it adds little beyond the schema; baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific pair of verbs (read + score) on a specific resource (a public https:// web page) and names the sibling it mirrors ('exactly as scan_text does'), so an agent can distinguish it from scan_text by input type alone. The output shape (score, band, reasons) is also previewed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly bounds where it applies ('public web page', 'web pages, plain text and PDF files') and where it does not ('private, local or internal addresses cannot'), and routes the thorough path via deep=true. It doesn't state a when-not vs scan_text beyond the equivalence hint, but the URL requirement makes the choice clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
check_ai_imagefind_hidden_instructionsscan_urlcleanup_textscan_textScore text 0 to 100 for chatbot habits like filler, em dashes and buzzwords, each one marked.
Score and rewrite AI-assisted prose while preserving names, numbers, quotes, links, and facts.
Scores whether a page reads as AI-generated and names the tells to fix.
Score a public website 0 to 100 for the design habits that make it look AI-made.
Add one secure layer between your agents and this server.