Document forensics: tamper/AI checks, extract, identity, PII, adverse media. No API key needed.
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.
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.
check_documentAInspectCheap 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 |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description fully discloses behavior: non-destructive, cheap (no cost), expects sha256 in lowercase hex, and returns {cached, warrant_id, permalink}.
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 concise sentences, front-loaded with purpose, instructions, and return value. No wasted 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 simplicity (one parameter, output schema present), the description covers all needed context: why, how, what to expect.
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, the description compensates by stating 'Hash the file yourself (sha256, lowercase hex)' and naming the expected input, though it could explicitly reference the parameter name sha256 in the description.
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 'Cheap cache-check: has this exact document already been inspected?' specifying the verb (check), resource (document), and distinguishing purpose from siblings like 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?
Explicitly advises calling this before verify_document to skip a redundant (paid) inspection, providing clear when-to-use context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_packAInspectCheck 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 |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Disclosures: coverage not approval, documents never stored, cheap classification (page-1 read), two checklist definition methods, and formats for documents. No annotations provided, but description fully compensates.
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, usage, then parameter details. Each sentence adds value, but could be slightly more concise (e.g., 'COVERAGE, not approval' sentence is repeated). Almost perfect.
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?
With output schema present, description briefly lists return fields. Covers all key aspects: purpose, usage, parameters, behavioral caveats, and return structure. Complete for a tool with 3 params and siblings.
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%, but description explains 'scheme' and 'requirements' parameters with examples and syntax, and documents parameter with constraints (up to 12, url or bytes_b64). Adds significant meaning beyond 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 'Check whether a SET of documents satisfies a checklist — completeness, cheaply.' Verb 'check', resource 'set of documents against a checklist', 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?
Explicitly says 'USE THIS WHEN you have an application / onboarding pack' and contrasts with verify_document, classify_document, verify_identity, providing clear when-to-use and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
classify_documentAInspectClassify 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 |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, description fully discloses behavior: it does not assess authenticity, abstains below confidence threshold, classifies non-financial documents as 'other', and does not store documents. No contradictions.
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, but slightly verbose. Could be tightened slightly without losing information, but still 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?
Complete for its purpose: covers inputs, behavior, scope, and links to related tools. Output schema exists, so return values are not needed in description, but it still mentions key output fields.
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% coverage, but description explains the two input modes (url or bytes_b64+filename), notes url is cheapest and fetched server-side, and filename is for routing. Adds essential meaning beyond 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?
The description clearly states the tool classifies a financial document's type and issuing country, and lists specific document types. This distinguishes it from sibling tools like 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?
Explicitly provides usage guidance: 'USE THIS WHEN someone shares a document... what kind of document is this?' and directs to use as first step before verify_document. Also specifies what not to use it for (authenticity checking).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
detect_ai_textAInspectEstimate 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 |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given no annotations, the description carries full transparency burden. It discloses that probability is model confidence, not calibrated truth, and warns of false-positives for templated/coached/non-native English. It also explains the 'applicable' flag and abstention for non-prose input. Could add rate limits or auth needs, but already strong.
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, usage, input methods, honest scope, and alternatives. It is slightly verbose but every sentence adds value. Could be trimmed by a few words, but overall 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?
The description covers input alternatives, scope, honest caveats, and alternative tools. Output schema exists so return details are not required; the description still mentions key output fields (probability, lean, tells, reasoning, applicable). It fully addresses what an agent needs to decide to invoke this 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?
With 0% schema description coverage, the description compensates well by explaining the three input methods (text, url, bytes_b64) and that exactly one must be provided. It adds that URL is the cheapest call and bytes_b64 needs filename. However, it does not specify format constraints for url or bytes_b64 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 tool estimates probability that text is AI-generated. It uses specific verb 'estimate' and resource 'probability of AI-generation'. It distinguishes from siblings like verify_document and verify_references by specifying context for non-prose documents.
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 text is AI-written (essays, cover letters, etc.). Also provides when-not: for form/table/numeric documents, and recommends alternatives: verify_document for authenticity and verify_references for citations/claims.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
extract_fieldsAInspectExtract 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 |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description fully discloses behavioral traits. It states the document is never stored, extraction is not verification, unclear fields are put in not_found, and page limits. It also describes the return structure. This meets the burden completely.
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 relatively long but well-structured and front-loaded. Every sentence adds value. However, there is slight redundancy in explaining the modes, and it could be tightened slightly. Still, it is 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 tool's complexity (7 parameters, no required, output schema exists), the description is fully complete. It covers purpose, usage, parameters, behavior, return format, and sibling differentiation. No gaps remain.
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 the description must explain all parameters. It does so in detail: fields (ad-hoc list or objects), template (named presets), url vs bytes_b64 (with cost implications), filename, country, max_pages (default and ceiling). This adds significant meaning beyond the bare 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 tool extracts structured fields from documents using a vision model. It distinguishes itself from siblings like verify_document and classify_document by specifying when to use each. The verb and resource are explicit, and the scope is well-defined.
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 and when-not-to-use guidance, including alternatives like verify_document and classify_document. It explains the three input modes (fields, template, auto) and gives examples and tips, such as using boolean for checkboxes. This is comprehensive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_warrantAInspectRetrieve a stored warrant by id (e.g. 'warrant_') — the full bundle as JSON, or a human-readable Markdown report when as_markdown=True.
USE THIS WHEN you have a warrant_id from an earlier verify_document / check_document call
and need the FULL evidence — every signal that fired, per-page findings, provenance — rather
than the summary the original call returned. Use as_markdown=True to get a report you can
show a human verbatim.| Name | Required | Description | Default |
|---|---|---|---|
| warrant_id | Yes | ||
| as_markdown | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. It discloses return content (full bundle, signals, per-page findings, provenance) but does not explicitly state safety (read-only), auth needs, or rate limits. Adequate but could be more transparent about non-destructive nature.
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 main action, uses line breaks for readability. Every word earns its place; no verbose 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?
Given the tool's simplicity (2 params, no output schema), description fully covers what the tool does, when to use, and what returns. No output schema needed since description explains return values.
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 compensates well. It explains warrant_id format ('warrant_<hex>') and as_markdown purpose. Adds value beyond schema, though could be more precise on warrant_id format.
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?
Description specifies the action (retrieve), resource (stored warrant by id), and differentiates two output formats (JSON or Markdown). It distinguishes from sibling tools by mentioning it is for full evidence from earlier verify_document/check_document calls.
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 you have a warrant_id from earlier calls and need full evidence. Also explains when to use as_markdown. Does not explicitly state when not to use, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
redact_piiAInspectDetect 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 |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description fully carries the transparency burden. It discloses two detection layers (regex+checksum and vision model), that the document is never stored, detection coverage is not guaranteed, and responses contain masked values only. No contradictions.
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 concise (~150 words), well-structured with purpose, usage, parameters, return details, and caveats. Every sentence adds value without 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 of PII detection, the description covers input formats, detection methods, output structure, limitations, and privacy guarantees. The presence of an output schema (not shown) is complemented by the description's explanation of return values.
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?
Despite 0% schema description coverage, the description adds meaning to all 4 parameters: explains that url must be a public http(s) link fetched server-side, bytes_b64 is inline base64 with a filename, and max_pages caps page count with a default and ceiling. This adds value beyond 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?
The description clearly states the tool detects and masks PII in documents, specifying the verb 'Detect and MASK' and the resource 'personally identifiable information in a document (PDF or image)'. It distinguishes from sibling tools like classify_document or verify_document by explicitly stating its unique functionality.
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 says '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', providing clear context for use. However, it does not explicitly mention when not to use it or alternative tools, though siblings have different purposes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
screen_adverse_mediaAInspectScreen 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 |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries the burden. It discloses statelessness, result structure, limitations (sanctions hits are 'possible', not confirmed), and the two identification methods. Could mention authentication or rate limits, but covers essential behavioral traits.
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 front-loaded purpose, usage paragraph, parameter explanation, and result description. Slightly verbose but every sentence 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 9 parameters, no annotations, and an output schema, the description covers identification methods, input semantics, output shape, limitations, and statelessness. Complete for correct tool 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?
Schema coverage is 0%, but description fully explains the two identification paths (name-based with optional fields, or document-based via url/bytes_b64). Adds meaning to dob, country, aliases, employer, role, and filename. Compensates completely for 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 it screens for adverse media and sanctions/PEP exposure (KYC/AML), using specific verbs and context. It distinguishes from sibling tools like verify_identity and classify_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?
Explicitly says 'USE THIS WHEN onboarding or due-diligence asks...' and mentions it pairs with verify_identity. Does not list all alternatives but provides clear context and a natural sibling relationship.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
submit_feedbackAInspectRecord 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.
USE THIS WHEN the ground truth became known after a verify_document call — e.g. the
document was later confirmed genuine or fraudulent — so the engine learns from the
outcome. Tell it what happened; it sharpens future inspections for everyone.| Name | Required | Description | Default |
|---|---|---|---|
| note | No | ||
| verdict | Yes | ||
| warrant_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose all behavioral traits. It specifies verdict must be 'up' or 'down' and note is optional, but doesn't mention idempotency, state changes, or potential side effects beyond learning.
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 short paragraphs: first explains what the tool does, second explains when to use it. Every sentence adds value, no fluff, logically structured.
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 feedback tool with three parameters, the description is complete enough. It explains the trigger (post-verification) and effect (learning). Output schema exists (though not shown), so return values need not be described.
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 compensates by explaining the 'verdict' parameter values ('up' or 'down'), clarifying 'note' is optional, and implying warrant_id from context (e.g., 'warrant_id'). Adds significant meaning beyond 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?
The description clearly states the tool records thumbs up/down on a warrant's rating, using specific verb 'Record' and resource 'warrant's rating'. It distinguishes from sibling tools (e.g., verify_document) by focusing on feedback after verification.
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 'USE THIS WHEN the ground truth became known after a verify_document call', providing clear context. No explicit when-not-to-use, but the use case is well-defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
verify_documentAInspectForensically 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 |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes inspection nature, return fields, caching behavior, and that it's a signal not verdict. No annotations provided, description carries full burden. Lacks explicit read/destructive hint but analysis tools are implicitly read-only.
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: opening purpose, usage guidance, parameter inputs, return description. Slightly long but each sentence 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?
Explains return fields (risk_band, etc.), mentions get_warrant for evidence, and caching behavior. With output schema present, return details are sufficient. No mention of error cases but acceptable for a complex 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 coverage 0%, but description adds meaning for url (cheapest call, server-side fetch), bytes_b64 (inline base64 with filename), and filename (routing). Fresh parameter not explained, but overall compensates for 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?
Explicitly states it forensically inspects documents for authenticity, tampering, AI-generation, etc. Distinguishes 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?
Provides explicit when-to-use scenarios (payslip, bank statement, etc.) and when-not-to-use (AI-written prose → detect_ai_text; citations → verify_references). Explains how to provide input via url or bytes_b64.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
verify_identityAInspectRun 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 |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses the two-phase process (vision model + deterministic engine), that it returns identity coverage not forgery, and that 'Documents are never stored.' This is thorough and 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?
Description is well-structured with clear sections (purpose, usage, parameters, behavior). While slightly long, every sentence adds value and is front-loaded.
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 (2 params, output schema exists but not detailed), description covers usage, parameter semantics, and behavioral notes. It references output format briefly, sufficient with an output schema 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 coverage is 0%, but description adds meaning: explains 'documents' format (url or bytes_b64, up to 10) and 'scheme' values with defaults. It compensates well for the lack of 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's purpose: 'Run an Australian identity check over a SET of identity documents.' It specifies the verb (verify), resource (identity), and distinguishes from siblings like verify_document (forgery) and check_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?
Explicit usage guidance: 'USE THIS WHEN someone needs to verify a person's identity from their documents — KYC / onboarding...' It also tells to pass all documents together and directs to verify_document 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_referencesAInspectFact-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 |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses server-side fetching, default vs deep mode, return format, and the honest boundary. Missing details on rate limits, auth, or size limits, but overall 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 front-loaded purpose. However, it is somewhat verbose and could be more concise while retaining key details.
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 (5 parameters, default vs deep mode, output schema), the description covers input options, behavior, return format, and limitations. It is complete and addresses the context signals well.
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%, but the description thoroughly explains all parameters: url, text, bytes_b64, deep, filename. It provides guidance on how to provide the document and the trade-offs, adding significant meaning beyond the raw 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 tool's purpose: 'Fact-check a document's REFERENCES and CLAIMS' for AI-generated reports. It specifies the document types and verification aspects, and distinguishes from sibling verification tools by focusing on references and claims.
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 includes explicit usage scenarios ('USE THIS WHEN') and discusses the honest boundary of reporting coverage vs truth. However, it does not explicitly exclude particular cases or contrast with sibling tools, reducing clarity slightly.
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.
No comments yet. Be the first to start the discussion!
