OpenWarrant — Document Verification Suite
Server Details
Verify, classify financial docs, detect AI text, fact-check citations. One server, full suite.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.6/5 across 12 of 12 tools scored. Lowest: 4/5.
Every tool has a clearly distinct purpose: cache check, type classification, field extraction, authenticity verification, identity verification, PII redaction, AI text detection, reference checking, pack completeness, adverse media screening, warrant retrieval, and feedback. The descriptions explicitly contrast similar tools (e.g., classify_document vs. extract_fields vs. verify_document).
All tool names follow a consistent verb_noun pattern in snake_case: check_document, check_pack, classify_document, detect_ai_text, extract_fields, get_warrant, redact_pii, screen_adverse_media, submit_feedback, verify_document, verify_identity, verify_references. No mixing of conventions.
12 tools is well-scoped for a document verification suite. Each tool covers a distinct aspect of the verification pipeline: caching, classification, extraction, authenticity, identity, PII, adverse media, AI text, references, pack completeness, feedback, and retrieval. Neither too many nor too few.
The tool surface is comprehensive for the domain of document verification: it covers document classification, field extraction, authenticity checks, identity checks, PII detection, AI text detection, reference verification, pack completeness, and adverse media screening. The only potential gaps (e.g., bulk operations or document comparison) are peripheral to the core purpose.
Available Tools
12 toolscheck_documentAInspect
Cheap cache-check: has this exact document already been inspected? Hash the file yourself (sha256, lowercase hex) and call this before verify_document to skip a redundant (paid) inspection. Returns {cached, warrant_id, permalink}.
| Name | Required | Description | Default |
|---|---|---|---|
| sha256 | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It states the tool is cheap and a cache-check (implying read-only), and explicitly lists the return fields {cached, warrant_id, permalink}. It does not disclose potential side effects or auth needs, but the read-only nature is strongly implied.
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 sentences with zero waste: first states purpose, second gives usage instructions, third states return value. Information is front-loaded and every sentence is essential.
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?
Given the tool's simplicity (one parameter, cache-check) and the presence of an output schema, the description covers purpose, usage parameter formatting, and return. No gaps remain for an agent to misuse the tool.
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 0%, so the description compensates fully. It instructs the agent to hash the file with sha256 in lowercase hex, providing format and computation guidance that the schema lacks.
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 clearly states the tool is a cheap cache-check to see if a document has already been inspected, with a specific verb and resource. It distinguishes from sibling verify_document by positioning it as a preliminary step to avoid redundant paid inspection.
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?
The description explicitly advises using this tool before verify_document to skip a redundant paid inspection, providing clear when-to-use context and a concrete alternative (verify_document) to avoid.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_packAInspect
Check whether a SET of documents satisfies a checklist — completeness, cheaply.
USE THIS WHEN you have an application / onboarding pack and need "do we have the required
documents, and what's still missing?" Each document is CLASSIFIED (one cheap page-1 read —
never full field extraction or multi-page), then matched against the checklist's required
slots. (For "is a document genuine?" use verify_document; to identify ONE document use
classify_document; for the identity gate use verify_identity.)
Define the checklist ONE of two ways:
- `scheme`: a named preset — "income_proof", "lending_prequal", "rental_application".
- `requirements`: an ad-hoc checklist — a list of document-type names like
["payslip","bank_statement"], or objects {"key":..., "accepts":[types], "optional":bool}.
`documents` is a list (up to 12), each ONE of: {"url": "https://..."} (public link, fetched
server-side) or {"bytes_b64": "...", "filename": "statement.pdf"} (inline).
Returns `{complete, slots[] (key, satisfied, matched), missing[], documents[] (filename,
classified_type), unmatched_documents[]}`. COVERAGE, not approval — that the right document
TYPES are present, NOT that any is genuine (run verify_document) or that an application is
approved. Documents are never stored.
| Name | Required | Description | Default |
|---|---|---|---|
| scheme | No | ||
| documents | Yes | ||
| requirements | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes scope (completeness only, not approval or genuineness), classification method (cheap page-1 read), output structure, and that documents are never stored. Lacks explicit read-only hint but implied.
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?
Well-structured with bullet points and front-loaded purpose. Some redundancy in sibling listings but overall efficient for the detail provided.
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?
Given no annotations, schema coverage 0%, and 3 params, description is comprehensive: covers purpose, usage, parameter meanings, output, and limitations. Output schema exists but description adds context.
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?
With 0% schema coverage, description fully explains each parameter: scheme as named preset, requirements as ad-hoc list, documents as list of up to 12 with two formats, including examples and constraints.
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?
Clearly states 'Check whether a SET of documents satisfies a checklist — completeness, cheaply.' Specifies verb+resource and distinguishes from siblings by naming alternatives.
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?
Explicit usage context: 'USE THIS WHEN you have an application / onboarding pack...' and when not to: for genuineness, identification, identity gate. Also explains two ways to define checklist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
classify_documentAInspect
Classify a FINANCIAL document's type and issuing country. Specialised in financial-services documents: payslip, tax_invoice, bank_statement, salary_certificate, payg_summary, receipt.
USE THIS WHEN someone shares a document (or a link to one) and asks: what kind of
document is this? is this a payslip / invoice / bank statement? route this document.
Also use it as the FIRST step before verify_document, so the right checks run.
Provide the document ONE way: `url` (a public http(s) link to a PDF or image — fetched
server-side, the cheapest call) OR `bytes_b64` (inline base64, plus `filename` for
PDF-vs-image routing). Returns `{document_type, country_code, confidence,
is_financial_document, evidence, ...}`.
HONEST SCOPE: type classification only — NOT an authenticity or fraud judgment (use
verify_document for that). Below the confidence threshold it abstains with 'unknown'
rather than guessing; non-financial documents classify as 'other'. The document is
never stored.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | ||
| filename | No | document.pdf | |
| bytes_b64 | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description fully covers behavioral traits: documents never stored, returns specific fields (document_type, country_code, etc.), abstains with 'unknown' below confidence, classifies non-financial as 'other'. Honest about scope and limitations.
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?
Well-structured with clear sections. Front-loaded with purpose, then usage guidance, parameter details, and behavioral transparency. Concise yet comprehensive without unnecessary words.
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?
Given the tool's moderate complexity and presence of output schema, the description covers all relevant aspects: purpose, when to use, parameters, behavior, and output fields. Leaves no critical gaps.
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 has 0% description coverage, but description compensates well by explaining the two input methods (url and bytes_b64), the role of filename for routing, and notes the cheapest call for url.
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 clearly states it classifies financial documents by type and issuing country, listing specific document types like payslip, tax_invoice, etc. It also distinguishes from sibling tools by focusing on classification, not authenticity.
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 says when to use: when someone asks what kind of document or as first step before verify_document. Also clarifies what not to use it for (authenticity/fraud). Provides specific context for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
detect_ai_textAInspect
Estimate the PROBABILITY that a document's text was AI-GENERATED (LLM-written prose).
USE THIS WHEN someone shares prose — an essay, cover letter, article, review, application,
or report (or a link to one) — and asks: did an AI / ChatGPT write this? is this
human-written? detect AI text.
Provide the document ONE way: `text` (pasted markdown/plain prose), `url` (a public http(s)
link to a page or PDF — fetched server-side, the cheapest call), OR `bytes_b64` (a base64
PDF/file, plus `filename` for routing). Returns
`{probability, lean, tells, reasoning, applicable}`.
HONEST SCOPE: the probability is the model's CONFIDENCE, not a calibrated truth — it can
false-flag templated/coached or non-native-English writing. It works on PROSE only: for a
form/table/numeric document (payslip, statement) it returns `applicable: false` and abstains,
because AI-text detection false-positives badly there — use `verify_document` (the
authenticity engine) for those, and `verify_references` to check a doc's citations/claims.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | ||
| text | No | ||
| filename | No | document.pdf | |
| bytes_b64 | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description fully covers behavior: probability is model confidence not calibrated truth, can false-flag templated/coached/non-native writing, works only on prose, returns applicable: false for non-prose. Comprehensive and honest.
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?
Description is well-structured: purpose sentence, usage guidelines, input options, output summary, honest scope. It's somewhat lengthy but front-loaded; every part adds value.
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?
Given no annotations, 4 parameters with 0% schema coverage, and an output schema, the description adequately covers input methods, output fields (probability, lean, tells, reasoning, applicable), and edge cases (non-prose). Complements the tool's complexity.
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 0%, but description explains the three input methods (text, url, bytes_b64) and their usage, including that 'url is the cheapest call' and bytes_b64 needs filename. Adds meaning beyond schema titles.
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 clearly states the tool estimates the probability of AI-generated text, using specific verbs like 'Estimate' and 'detect'. It distinguishes itself from siblings by mentioning alternatives like verify_document and verify_references for different use cases.
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?
Explicit usage guidance: 'USE THIS WHEN someone shares prose... and asks: did an AI write this?' Also specifies when not to use it (forms, tables, numeric docs) and directs to verify_document or verify_references instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
extract_fieldsAInspect
Extract structured FIELDS from a document (PDF or image) with a vision model.
USE THIS WHEN you need specific values OUT of a document — a payslip's gross/net, an invoice's
total/ABN, a form's checkboxes, a table's cells — rather than a yes/no about the document. (For
"is this genuine?" use verify_document; for "what kind of document is this?" classify_document.)
Say WHAT to pull, four ways:
- `fields`: an ad-hoc list — names like ["gross_pay","abn"], or objects
{"name":..., "type":"text|amount|date|boolean", "description":...}. THE general case: ask
for exactly the fields your task needs. Use type "boolean" for a checkbox/tickbox.
- `template`: a named preset — "payslip", "tax_invoice", "bank_statement", "receipt".
- NEITHER: AUTO — the document is classified and that type's fields are used.
- auto on an unrecognised type: schema-free — every labelled field is returned.
Provide the document ONE way: `url` (a public http(s) link — fetched server-side, the cheapest
call) OR `bytes_b64` (inline base64, plus `filename` for PDF-vs-image routing). `country` is an
optional hint; `max_pages` caps how many pages are read (default a few; hard ceiling 10).
Returns `{mode, document_type, fields{name:{value,confidence,page}}, not_found, pages_read,
page_limit}`. EXTRACTION, not verification — values are what the document SHOWS, not proof it is
genuine. A field that isn't clearly present comes back in `not_found` (it abstains rather than
guessing). The document is never stored.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | ||
| fields | No | ||
| country | No | ||
| filename | No | document.pdf | |
| template | No | ||
| bytes_b64 | No | ||
| max_pages | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses important behaviors: extraction is not verification; values are what the document shows, not proof of genuineness; missing fields go to 'not_found' (abstains, not guesses); document is never stored; max_pages has default and hard ceiling. It could mention error handling (e.g., when both url and bytes_b64 provided) but overall highly transparent.
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 description is well-structured with sections and clear formatting. It is front-loaded with purpose and usage. Each sentence adds value, though it is somewhat lengthy. Could potentially shorten some examples, but overall efficient for the complexity.
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?
Given the complexity (7 parameters, no annotations, with output schema), the description is complete. It explains the return format (mode, document_type, fields with value/confidence/page, not_found, pages_read, page_limit), covers error behavior (not_found), and mentions that the document is not stored. Sibling context is handled via usage guidelines.
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 0%, so description must compensate. It does so thoroughly: explains the four ways to specify extraction (fields array with detailed structure, template, auto, and fallback), document input methods (url, bytes_b64 with filename), country as hint, and max_pages cap. Adds rich meaning beyond schema titles.
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 clearly states the tool's purpose: 'Extract structured FIELDS from a document (PDF or image) with a vision model.' It distinguishes from siblings by specifying when to use (e.g., 'is this genuine?' -> verify_document; 'what kind of document is this?' -> classify_document). The verb 'extract' and resource 'FIELDS from a document' are specific and unambiguous.
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?
The description explicitly states when to use: 'USE THIS WHEN you need specific values OUT of a document' and provides clear alternatives: 'For "is this genuine?" use verify_document; for "what kind of document is this?" classify_document.' It also explains the four ways to specify what to pull (fields, template, auto) and how to provide the document.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_warrantAInspect
Retrieve a stored warrant by id (e.g. 'warrant_') — the full bundle as JSON, or a human-readable Markdown report when as_markdown=True.
| Name | Required | Description | Default |
|---|---|---|---|
| warrant_id | Yes | ||
| as_markdown | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It indicates a read operation with two output formats but does not disclose error handling, side effects, or authorization needs. The behavior is implied but not fully transparent.
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 description is a single, well-structured sentence that front-loads the action and resource, then explains the output options. Every word contributes, with no redundancy or fluff.
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?
Given the lack of output schema and annotations, the description covers the essential inputs and outputs. It explains both parameters and the two result formats. However, it omits details on return structure and error scenarios, which would be needed for full completeness.
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?
The schema has 0% description coverage, so the description must compensate. It explains the format for warrant_id ('warrant_<hex>') and the role of as_markdown (toggle for Markdown output). This adds meaningful context beyond the schema's bare structure.
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 clearly states the action ('Retrieve a stored warrant by id') and the resource ('warrant'), with distinct output formats (JSON or Markdown). It is specific and sets it apart from sibling tools like check_document, submit_feedback, and verify_document.
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?
The description does not explicitly state when to use this tool versus alternatives or provide context on prerequisites or exclusions. It implicitly assumes use for retrieving a warrant by its ID, but lacks the depth to guide an agent in distinguishing it from sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
redact_piiAInspect
Detect and MASK personally identifiable information in a document (PDF or image).
USE THIS WHEN you need to know what PII a document contains, or to get a redacted copy before
forwarding / logging / passing it to another model. Two layers: a deterministic regex+checksum
pass for structured identifiers (emails, payment cards, SSN, PAN, ABN) and a vision model for
the unstructured PII — names, addresses, dates of birth, phone numbers, and photo/signature
presence.
Provide the document ONE way: `url` (a public http(s) link, fetched server-side) or `bytes_b64`
(inline base64, plus `filename`). `max_pages` caps how many pages are read (default a few;
ceiling 10).
Returns `{pii_found, by_type, items[] (type, masked preview, method), redacted_text, has_photo,
has_signature}`. Values are MASKED in the response — the raw PII is never returned. DETECTION
coverage, not a guarantee: it may miss PII or over-flag, so review before relying on it for
compliance. The document is never stored.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | ||
| filename | No | document.pdf | |
| bytes_b64 | No | ||
| max_pages | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully covers behavior: two detection layers (regex+checksum and vision model), output of masked values (never raw PII), limitations (may miss or over-flag), and that the document is never stored. This is comprehensive and leaves no ambiguity.
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 description is efficiently written with no wasted sentences. It opens with purpose, moves to usage guidance, then parameter details, return format, and caveats. Every sentence adds essential information and is well-organized.
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?
Given the tool's complexity (multiple input methods, two-layer detection, security concerns), the description covers all necessary aspects: purpose, usage, parameters, detection method, return values (including pii_found, by_type, items, redacted_text, has_photo, has_signature), limitations, and data handling. The presence of an output schema does not detract from the completeness of the textual description.
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?
The input schema has 0% description coverage, but the description explains each parameter: url must be http(s) and fetched server-side, bytes_b64 is inline base64 with filename, max_pages has a default and ceiling of 10. It clarifies that only one input method should be used. This adds critical meaning beyond the schema types.
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 clearly states the verb 'Detect and MASK' and the resource 'personally identifiable information in a document'. It distinguishes from siblings like 'classify_document' and 'verify_document' by focusing on PII detection and redaction. The phrase 'USE THIS WHEN...' provides explicit use cases.
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?
The description provides explicit scenarios for when to use the tool: knowing PII content or obtaining a redacted copy before forwarding/logging/passing to another model. It does not explicitly state when not to use or list alternatives, but the sibling context implies alternatives for non-redaction tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
screen_adverse_mediaAInspect
Screen a person or organisation for ADVERSE MEDIA and SANCTIONS/PEP exposure (KYC/AML).
USE THIS WHEN onboarding or due-diligence asks: does this subject appear in negative news
(fraud, money laundering, bribery, sanctions, trafficking, enforcement action), or on a
sanctions / politically-exposed-person list? Pairs naturally after verify_identity.
Identify the subject ONE of two ways: pass `name` (plus any of `dob` as YYYY-MM-DD, `country`,
`aliases`, `employer`, `role` — these sharpen matching and cut same-name false positives), OR
pass an identity document via `url`/`bytes_b64` (+`filename`) and the subject is read from it.
Returns `{subject, sanctions{...}, adverse_media{...}, risk_flag, headline, limitations}`:
sanctions candidates are corroboration-gated (a name-only hit is `possible`, NEVER confirmed —
one common name matches several different people); media hits are entity-disambiguated and
classified, with same-name articles surfaced under `excluded`. This is screening COVERAGE, not a
determination — a hit means "review this", not "guilty"; "nothing found" is not a clean record.
Stateless — nothing is stored.
| Name | Required | Description | Default |
|---|---|---|---|
| dob | No | ||
| url | No | ||
| name | No | ||
| role | No | ||
| aliases | No | ||
| country | No | ||
| employer | No | ||
| filename | No | document.pdf | |
| bytes_b64 | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavioral traits: stateless, no storage, returns screening coverage not determination, hits mean review, same-name issues, sanctions are corroboration-gated, and 'nothing found' is not clean. This is comprehensive transparency.
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 description is well-structured with clear sections: purpose, use case, two identification methods, return value breakdown, and important caveats. Every sentence adds value, and there is no 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?
Given the complexity (9 parameters, no annotations, output schema exists), the description is complete. It covers usage patterns, output structure, limitations, and behavioral disclaimers, leaving no major gaps for an AI agent to understand correct invocation.
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?
Although the schema has no parameter descriptions, the description explains all 9 parameters in context: the two identification methods (name+optional details vs document via url/bytes_b64+filename), the purpose of each field, and how they reduce false positives. It compensates fully for the missing schema descriptions.
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 clearly states the tool screens for adverse media and sanctions/PEP exposure, using a specific verb and resource. It distinguishes from siblings by mentioning it pairs after verify_identity, and specifies the KYC/AML due diligence context.
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?
The description explicitly states when to use the tool (onboarding or due-diligence asking about negative news or sanctions/PEP lists) and notes it pairs with verify_identity. However, it does not explicitly mention when not to use it or provide alternative sibling tools for different scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
submit_feedbackAInspect
Record thumbs up/down on a warrant's rating (the engine's precision-flywheel label source). verdict must be 'up' or 'down'; note is optional free text.
| Name | Required | Description | Default |
|---|---|---|---|
| note | No | ||
| verdict | Yes | ||
| warrant_id | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full burden. It accurately describes the tool's action and input constraints but does not disclose behavioral traits like side effects, idempotency, authentication needs, or whether existing feedback is overwritten. The description is adequate but lacks depth for a mutation tool.
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?
Two sentences, front-loaded with the core action, followed by precise parameter constraints. No unnecessary words, highly efficient.
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?
Given no annotations and an output schema existing, the description covers the tool's purpose and required inputs well. However, it omits any mention of what the tool returns (even though output schema exists) and potential constraints like rate limits or preconditions. Slightly incomplete for a complete picture.
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 0%, meaning the schema provides no parameter descriptions. The description adds meaning by clarifying verdict allowed values ('up' or 'down') and note's optionality. For warrant_id, it's implied by context. This compensates for the schema gap, though not all parameters get equal treatment.
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 clearly states the tool records thumbs up/down feedback on a warrant's rating, with specific reference to 'precision-flywheel label source'. This verb+resource combination distinguishes it from sibling tools (check_document, get_warrant, verify_document) which do not involve feedback submission.
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?
The description provides parameter guidelines (verdict must be 'up' or 'down', note optional) but does not explicitly state when to use this tool versus alternatives. The context with siblings implies it is for submitting feedback after checking/verifying, but no direct comparison or when-not guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
verify_documentAInspect
Forensically inspect a document (PDF or image) for authenticity: tampering signs, AI-generation indicators, arithmetic reconciliation (financial docs), and provenance.
USE THIS WHEN someone shares a payslip, bank statement, invoice, receipt, ID, certificate,
or contract and asks: is this genuine / real / authentic? has it been edited, doctored, or
photoshopped? can I trust this file? (For "did an AI *write* this prose" use detect_ai_text
on /mcp-aitext; for "are this report's citations real" use verify_references on /mcp-verify.)
Provide the document ONE way: `url` (a public http(s) link — fetched server-side, the
cheapest call: no need to download or encode anything) OR `bytes_b64` (inline base64, plus
`filename` so PDF-vs-image routing is right).
Returns the headline result — `risk_band` (low/medium/high/insufficient/error),
`inspection_quality` (coverage, orthogonal to risk), `recommended_action`, a `summary`, the
RISK-axis `risk_findings`, and a shareable `permalink`. This is a SIGNAL, not a fraud
verdict — a human or agent adjudicates. Use `get_warrant(warrant_id)` for the full evidence
bundle. Identical bytes are cached by content hash — `check_document` first skips a
redundant, paid inspection.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | ||
| fresh | No | ||
| filename | No | document.pdf | |
| bytes_b64 | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that the result is a signal not a verdict, mentions caching, and describes return fields. However, it does not mention rate limits, authentication, or error handling.
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?
Well-structured: purpose first, then usage guidelines, parameters, output. Somewhat lengthy but every sentence adds value. Could trim slightly.
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?
Given complexity (4 params, no annotations, output schema exists), description covers purpose, usage, parameters, and output. Missing explanation for 'fresh' param and error handling, but otherwise comprehensive.
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 has 0% description coverage. Description explains url (cheaper) vs bytes_b64+filename, but does not explain the 'fresh' parameter. Partially compensates for schema lack.
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 clearly states the tool's purpose: forensic inspection of documents for authenticity, tampering, AI-generation, etc. It lists specific document types and questions it addresses, and distinguishes it from siblings like detect_ai_text and verify_references.
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 states when to use (when someone asks if a document is genuine) and when not (for AI-written prose or citation verification). It also advises using check_document first to avoid redundant calls.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
verify_identityAInspect
Run an Australian identity check over a SET of identity documents. A vision model reads each document (which ID it is, which fields it shows — name/photo/address/signature — and its issue date); a deterministic engine then tallies them against a scheme and reports whether identity is established, and exactly what's still missing if not.
USE THIS WHEN someone needs to verify a person's identity from their documents — KYC /
onboarding / "do these documents satisfy the 100-point check?" Pass ALL the person's
documents together (a passport alone is 70 points; the check needs >= 100).
`documents` is a list, each item ONE of: {"url": "https://..."} (public link, fetched
server-side) or {"bytes_b64": "...", "filename": "passport.pdf"} (inline). Up to 10.
`scheme`: "afp_100_point" (points, default) or "austrac_safe_harbour" (category combinations).
Returns `{established, points/target or satisfied_path, documents[] (per-document: type,
fields shown, whether it counted and why-not), reason, accepts, ...}`. This is identity
COVERAGE, not a forgery judgment — run verify_document for authenticity. Documents are
never stored.
| Name | Required | Description | Default |
|---|---|---|---|
| scheme | No | afp_100_point | |
| documents | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It transparently explains the process: vision model reads documents, deterministic engine tallies them, reports status and missing items. It notes documents are never stored. Could explicitly state it's a read-only operation, but overall good transparency.
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?
Well-structured with two paragraphs: first describes tool behavior, second provides usage guidance and parameter details. Slightly wordy but every sentence adds value. Could be slightly more concise, but effective.
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?
Given the tool's complexity (multiple documents, two schemes, detailed output), the description covers all essential aspects: purpose, parameters, output summary, and key caveat (not forgery). Output schema exists, so return value details are not needed.
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 0%, so description must fully explain parameters. It does: documents are a list of objects with url or bytes_b64, up to 10 items; scheme has two options with defaults. Adds formatting and constraints absent from 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?
The description clearly states the verb ('verify'), resource ('identity'), and scope ('Australian identity check over a SET of identity documents'). It differentiates from sibling tools by explicitly contrasting with verify_document, which checks forgery, not coverage.
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?
Provides explicit when-to-use: 'USE THIS WHEN someone needs to verify a person's identity from their documents — KYC / onboarding / do these documents satisfy the 100-point check?'. Also gives a clear alternative: 'run verify_document for authenticity' for forgery checks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
verify_referencesAInspect
Fact-check a document's REFERENCES and CLAIMS — built for AI-generated reports whose citations must be checked before they're trusted.
USE THIS WHEN someone shares a report, article, whitepaper, or deep-research export (or a
link to one) and asks: is this accurate / legit? are these citations real? fact-check this.
did the AI make this up? Also use it proactively before relying on any AI-written document.
Provide the document ONE way: `url` (a public http(s) link to a PDF or web page — fetched
server-side, the cheapest call: no need to download or encode anything), `text` (pasted
markdown/plain prose), OR `bytes_b64` (a base64 PDF; URLs are read from the PDF's link
annotations, so they're exact). Default (fast): provenance (is it a ChatGPT deep-research
export?), citation resolution (live / archived / dead, papers matched against arXiv/Crossref
to catch 'real ID, wrong paper'), and internal MATH (recompute the doc's own arithmetic).
Set `deep=true` to also fetch each cited source and judge whether it SUPPORTS or CONTRADICTS
the claim (slower, ~a minute).
Returns a trust summary, per-item tables, and a shareable `permalink` to the public
fact-check record. HONEST BOUNDARY: this reports verification COVERAGE, not truth —
'supported' means evidence-backed (not necessarily true) and 'unsupported' means no evidence
found (not necessarily false). It tells a reviewer WHERE to look; it does not bless the
document, and it never affects the fraud risk band.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | ||
| deep | No | ||
| text | No | ||
| filename | No | document.pdf | |
| bytes_b64 | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses behavioral traits: input methods, default vs deep mode, the honest boundary about reporting coverage not truth, and implications for 'supported' and 'unsupported'. It also notes that the tool never affects the fraud risk band and doesn't bless the document.
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 description is well-structured with paragraphs for different aspects (usage, input, behavior, boundary). It is slightly verbose but every section adds value; no unnecessary sentences. Could be tightened slightly without loss of clarity.
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 complex tool with 5 parameters, no required parameters, and an output schema (so return values explained elsewhere), the description covers all essential aspects: purpose, usage context, input methods, default vs deep behavior, and honest boundaries. It is fully self-contained for an agent to decide when and how to use it.
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 0%, so the description must compensate. It explains each parameter: url (public http(s) link, cheapest), text (pasted markdown), bytes_b64 (base64 PDF), deep boolean, and filename (defaulted). It adds context about how each input is used (e.g., URL fetched server-side, PDF bytes for link annotations).
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 clearly states the tool's purpose: fact-checking references and claims in documents, especially AI-generated reports. It lists specific use cases (e.g., verifying citations, checking if AI made something up) and distinguishes from siblings by focusing on verification of references rather than general document classification or detection.
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?
The description provides explicit when-to-use scenarios (e.g., when someone asks 'is this accurate?' or proactively before relying on AI-written documents). However, it does not mention when not to use it or suggest alternative tools among siblings, which would elevate clarity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!