sifter-mcp is an MCP server for Sifter, an open-source document intelligence engine that extracts structured data from documents and enables querying and management of the extracted records.
Sift Management
list_sifts, get_sift, create_sift, update_sift, delete_sift — create and manage sifts (extraction configurations) using natural language instructions (e.g. "client, date, total amount")
Document & Folder Management
list_folders, get_folder — browse and inspect document folders
upload_document — upload a Base64-encoded file to a folder (folder is auto-created; linked sifts will automatically process the document)
Extraction
run_extraction — enqueue a document for extraction against a specific sift
get_extraction_status — check whether extraction is queued, running, completed, or failed
Querying & Retrieval
list_records — paginate through extracted structured records (cursor-based)
find_records — filter records using structured MongoDB-style criteria (e.g. {"total": {"$gt": 1000}})
query_sift — ask a natural language question over a sift's records; Sifter generates and runs the query automatically
aggregate_sift — run a raw MongoDB aggregation pipeline directly for custom analytics
get_record_citations — retrieve per-field citation details (page, bounding box, source text) for any extracted record
Your documents are a dark database.
Open-source document intelligence engine — schema-driven extraction, NL query, MCP server, Python and TypeScript SDKs. Self-hostable under MIT.
RAG is built for retrieval — find me chunks similar to this query. It breaks on homogeneous collections like invoices, contracts, or receipts where every document looks alike and the question is an aggregation, not a search.
Sifter's approach: extract structured fields once (client, date, total), store them as typed records, query with real filters and aggregations. The answer is exact and reproducible — because it's a database query, not a similarity search.
Related MCP server: API Agent
git clone https://github.com/sifter-ai/sifter
cd sifter/code
cp server/.env.example server/.env.local # set SIFTER_DEFAULT_API_KEY (required)
docker compose up -dOpen http://localhost:3000 — create a sift, upload documents, query results.
pip install sifter-aifrom sifter import Sifter
s = Sifter(api_key="sk-...")
sift = s.create_sift("Invoices", "client name, date, total amount")
sift.upload("./invoices/")
sift.wait()
for record in sift.records():
print(record["extracted_data"])
# {"client": "Acme Corp", "date": "2024-01-15", "total_amount": 1500.0}npm install @sifter-ai/sdkimport { Sifter } from "@sifter-ai/sdk";
const client = new Sifter({ apiKey: "sk-..." });
const sift = await client.createSift("Invoices", "client, date, total amount");
await sift.upload("./invoices/");
await sift.wait();
const records = await sift.records();
console.log(records);{
"mcpServers": {
"sifter": {
"command": "uvx",
"args": ["sifter-mcp", "--base-url", "http://localhost:8000"],
"env": { "SIFTER_API_KEY": "sk-dev" }
}
}
}Then ask:
"What's the total unpaid across all invoices from last quarter?" "Show me all contracts expiring in the next 90 days." "Which candidates have Python and more than 5 years experience?"
Sifter answers with structured data — exact counts, sums, filtered rows. Not a text blob.
Want a remote MCP URL without running a local server? → Sifter Cloud
Sifter includes a built-in dashboard — no Metabase, no Grafana, no SQL required.
Describe what you want to see in plain language:
sift = client.sifts.get("invoices")
sift.create_dashboard("Show total invoiced and unpaid by vendor, monthly trend")Produces KPI tiles, breakdowns, and time-series — updated automatically on every extraction.
Schema-driven extraction — describe what to extract in natural language; schema is inferred automatically and exported as Pydantic / TypeScript types
NL query — ask questions in plain language; Sifter generates inspectable MongoDB aggregation pipelines
MCP server — stdio transport, read + write tools, zero custom integration code
REST API + SDKs — full OpenAPI spec, typed clients for Python and TypeScript
Webhooks — HMAC-signed HTTP callbacks on every extraction event
Spec-driven dashboards — short NL spec → auto-generated board (KPI, breakdown, table, time series)
CLI — sifter extract, sifter records, sifter sifts for terminal workflows and CI
Self-hostable — Docker Compose, bring your own MongoDB and LLM API key
Sifter Cloud is the managed version — no Mongo, no ops, remote MCP endpoint, Google Drive and email ingress. Free tier available.
Full documentation at docs.sifter.run — quickstart, SDK reference, MCP guide, cookbook, self-hosting.
MIT — see LICENSE.
Created by Bruno Fortunato.
Run a MongoDB aggregation pipeline against a sift's records.
Args:
sift_id: The sift identifier
pipeline: MongoDB aggregation pipeline stages
e.g. [{"$group": {"_id": "$client", "total": {"$sum": "$total"}}}]
Returns:
Array of aggregated rows
| Name | Required | Description | Default |
|---|---|---|---|
| sift_id | Yes | ||
| pipeline | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description explains the tool runs an aggregation and returns rows, but does not disclose destructive potential, authorization needs, or performance implications. With zero annotation coverage, the description is adequate but not thorough.
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 highly concise: 3 sentences with a clear structure (purpose, parameter definitions, return). The example is front-loaded. No superfluous information.
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 MongoDB aggregation and no output schema, the description covers the main aspects: operation type, key parameters, return type. The example aids understanding. However, it could mention validation, error handling, or that the pipeline must be valid aggregation stages.
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 explain parameters. It defines both sift_id and pipeline, and provides a concrete example of pipeline format. This adds significant value beyond the schema, though more detail on pipeline constraints would improve it.
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 runs a MongoDB aggregation pipeline against a sift's records. It uses specific verb 'run' and resource 'aggregation pipeline against sift records', distinguishing it from siblings like query_sift or find_records.
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 no guidance on when to use this tool vs alternatives (e.g., query_sift, find_records). It doesn't mention prerequisites, context, or when not to use aggregation. Agents receive no decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new sift with the given extraction instructions.
Args:
name: Human-readable sift name
instructions: Natural language extraction instructions (e.g. "client, date, total")
folder_path: Optional folder path to link (e.g. '/invoices/2025'); created if it doesn't exist
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| instructions | Yes | ||
| folder_path | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description bears full responsibility for behavioral disclosure. It does not mention side effects, idempotency, conflict behavior, or what happens if a sift with the same name exists. Only parameter descriptions are given.
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 very concise: one line for purpose, then a list of args. No extraneous information. Front-loaded with the main purpose.
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 explains parameters but omits expected output (e.g., does it return the created sift ID?), error conditions, or any constraints. For a creation tool, return value is relevant 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?
Despite 0% schema description coverage, the description adds meaningful context: 'Human-readable sift name', 'Natural language extraction instructions (e.g. ...)', and 'Optional folder path ...; created if it doesn't exist'. This goes beyond the bare 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's action: 'Create a new sift with the given extraction instructions.' The verb 'Create' and resource 'sift' are specific, and it distinguishes from siblings like delete_sift or update_sift.
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 lacks explicit guidance on when to use this tool versus alternatives. It does not mention prerequisites or scenarios where other tools (e.g., update_sift) are more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a sift and all its records.
Args:
sift_id: The sift identifier
| Name | Required | Description | Default |
|---|---|---|---|
| sift_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the destructive behavior of deleting both the sift and its records, but with no annotations provided, it lacks details on permissions, reversibility, or other side effects.
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 extremely concise, with a single sentence and an explicit argument list. Every element is necessary and no words are wasted.
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?
While the tool is simple (one parameter, no output schema), the description lacks information on return values, error cases, or when to use compared to other tools.
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 description adds minimal meaning by restating 'sift_id' as 'The sift identifier', but with 0% schema coverage, more detail on the parameter's source or format would be helpful.
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 'Delete' and the resource 'sift', and specifies it also deletes all records. It distinguishes itself from sibling tools like create_sift or update_sift.
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?
No guidance is provided on when to use this tool versus alternatives, nor does it mention any prerequisites or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Filter records with structured criteria (no LLM roundtrip).
Args:
sift_id: The sift identifier
filter: Mongo-subset filter dict e.g. {"total": {"$gt": 1000}}
sort: Optional sort spec e.g. [["date", -1]]
limit: Max records to return (default 50)
cursor: Opaque pagination cursor from a previous call
Returns:
{"records": [...], "next_cursor": "..." | null}
| Name | Required | Description | Default |
|---|---|---|---|
| sift_id | Yes | ||
| filter | Yes | ||
| sort | No | ||
| limit | No | ||
| cursor | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It explains the filtering behavior and return format, but does not disclose side effects, permissions, or performance considerations.
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: a one-line summary followed by a clear Args/Returns structure. Every sentence adds value with 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 no output schema, the description adequately covers return format and pagination. Parameter explanations are sufficient for the tool's complexity (5 params, nested objects), though error handling is omitted.
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 adds significant meaning by detailing each parameter with examples (e.g., filter dict, sort spec, pagination cursor), going beyond type-only 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 it filters records with structured criteria and explicitly distinguishes it from LLM roundtrip approaches, giving a specific verb-resource pairing.
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 implies usage for structured filtering (no LLM), but does not explicitly state when to use this tool versus alternatives like query_sift or list_records. No exclusions or direct sibling differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check extraction status for a document on a sift.
Args:
document_id: The document identifier
sift_id: The sift identifier
Returns:
{"status": "queued|running|completed|failed", "error": "..." (on failure)}
| Name | Required | Description | Default |
|---|---|---|---|
| document_id | Yes | ||
| sift_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It states that the tool checks status and returns a status object, but does not disclose whether it is read-only, any side effects, rate limits, or authentication requirements. The return structure is helpful.
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 with no wasted words, using a clear docstring format. 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 no output schema, the description usefully includes the return structure. However, it lacks context on when to use this tool vs siblings, and no error handling details beyond the return schema.
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, and the description's param explanations ('The document identifier', 'The sift identifier') merely restate what is obvious from names and types. No additional meaning, constraints, or sources are provided.
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: checking extraction status for a document on a sift. This is a specific verb+resource combination that distinguishes it from siblings like run_extraction or query_sift.
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 implies usage after starting extraction but does not explicitly state when to use this tool versus alternatives like run_extraction or query_sift. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get folder metadata, linked sifts, and document list for a specific folder.
Args:
folder_path: Folder path (e.g. '/invoices/2025')
| Name | Required | Description | Default |
|---|---|---|---|
| folder_path | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must fully disclose behavior. It states the tool retrieves metadata, sifts, and documents, implying a read operation. However, it omits details like authorization requirements 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?
Two concise sentences; purpose and parameter explanation are front-loaded. No fluff, though a structured list could improve readability.
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?
High-level description of outputs (metadata, linked sifts, document list) but lacks detail on return format or fields. No mention of error scenarios despite lacking output schema. Adequate for a simple tool but leaves 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 adds an example path '/invoices/2025' and labels it as folder path, adding meaning beyond type 'string'. Could specify format constraints (e.g., leading slash).
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?
Clear verb 'Get' and resource 'folder', specifies three output categories. Distinguishes from sibling 'list_folders' (which lists all folders) by targeting a specific folder.
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?
No explicit guidance on when to use this tool vs alternatives like 'list_folders' or 'get_sift'. No prerequisites or exclusivity mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get per-field citation map for a record (page, bbox, source text for each field).
Args:
sift_id: The sift identifier
record_id: The record identifier
| Name | Required | Description | Default |
|---|---|---|---|
| sift_id | Yes | ||
| record_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must carry the full burden. It discloses the output includes page, bbox, and source text, implying a read operation, but does not explicitly state it's read-only or mention side effects or performance characteristics.
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 brief and to the point, but the Args section largely duplicates the schema without adding value. Could be more efficient by integrating parameter purpose into the main sentence.
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 output schema and low schema description coverage, the description should provide more context about the return structure, error cases, and usage. It only minimally describes the output format, leaving agents with incomplete information for 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?
Schema description coverage is 0%, and the description only lists parameter names without providing any additional meaning beyond the schema. It does not explain what 'sift_id' or 'record_id' represent or how they relate to the citation map.
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: get per-field citation map for a record, including page, bbox, and source text. It distinguishes from sibling tools like list_records or get_sift, which serve different functions.
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?
No guidance on when to use this tool vs alternatives. The description does not mention prerequisites, post-conditions, or alternative tools. Agents are left to infer appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get sift metadata and inferred extraction schema for a specific sift.
| Name | Required | Description | Default |
|---|---|---|---|
| sift_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry the burden. It only states the operation is a get, but does not disclose read-only nature, authentication needs, error behavior, or any side effects.
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?
Single sentence, directly front-loads the action and object. No wasted words, but lacks necessary detail.
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 output schema and simple parameters, the description is incomplete. It omits what the response contains, error scenarios, and relationships to sibling tools.
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% and description adds no meaning to the sole parameter sift_id. It does not explain format, type, or constraints 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 verb 'Get' and the resource 'sift metadata and inferred extraction schema'. It specifies the target is a specific sift, distinguishing it from list_sifts and other sibling tools.
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?
No guidance on when to use this tool versus alternatives, no when-not scenarios mentioned. The description only states what it does, not the context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List folders with their name and document count.
Args:
limit: Maximum number of folders to return (default 100, max 200)
offset: Number of folders to skip for pagination
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| offset | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. It fails to mention aspects like pagination behavior (beyond parameters), sorting, or whether subfolders are included. The read-only nature is implied but not explicitly stated.
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 extremely concise with a clear front-loaded purpose and a brief Args section. Every sentence serves a purpose with 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 no output schema, the description helpfully states the returned fields. It could mention total count, sorting, or permissions, but for a simple list tool, it is reasonably complete.
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 schema coverage is 0%, the description adds meaningful constraints: limit has default 100 and max 200; offset has default 0. This clarifies usage beyond the bare schema properties.
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 'List' and the resource 'folders', and specifies the returned fields ('name and document count'). However, it does not explicitly differentiate from sibling tools like 'get_folder' which likely retrieves a single folder.
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?
No guidance is provided on when to use this tool versus alternatives such as 'get_folder' or 'list_records'. The description lacks context about appropriate scenarios or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get extracted records from a sift.
Args:
sift_id: The sift identifier
limit: Maximum number of records to return (default 20, max 100)
offset: Number of records to skip (ignored when cursor is provided)
cursor: Opaque pagination cursor from a previous call's next_cursor field
| Name | Required | Description | Default |
|---|---|---|---|
| sift_id | Yes | ||
| limit | No | ||
| offset | No | ||
| cursor | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does not disclose whether the operation is read-only, destructive, or requires special permissions. The pagination behavior is implied but not explicitly stated as safe.
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 structured as a clear list with parameter details. It is moderately concise, though the overall length could be reduced by combining purpose and parameters.
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?
While parameters are well-covered, the description omits the return value format, any output schema, and safety information. Without annotations, it feels incomplete for a tool with 4 parameters.
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 fully compensates by explaining each parameter's purpose, defaults, and interactions (e.g., offset ignored when cursor provided). This adds significant 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 opens with 'Get extracted records from a sift,' which clearly states the verb and resource. However, it does not differentiate from sibling tools like 'find_records' or 'query_sift' that may return similar data.
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?
There is no guidance on when to use this tool versus alternatives, when not to use it, or what prerequisites are needed. The description only lists parameters without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List sifts with their name, instructions, and document/record counts.
Args:
limit: Maximum number of sifts to return (default 50, max 200)
offset: Number of sifts to skip for pagination
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| offset | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits like idempotency, authorization needs, or rate limits. It only states the function, missing important context for safe invocation.
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?
Concise two-sentence description plus parameter details. No extraneous words; every sentence provides 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?
No output schema, but description lists returned fields. Lacks details on sorting, errors, or edge cases, but for a simple list tool it is nearly complete.
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 adds constraints (limit max 200, offset for pagination) and default values, significantly enhancing understanding 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 lists sifts with specific fields (name, instructions, counts), distinguishing it from sibling tools like 'get_sift' (single) or 'create_sift' (creation).
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?
No explicit guidance on when to use this vs alternatives (e.g., 'get_sift' for a single sift). Usage is implied as a standard list operation, but no exclusions or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a natural language query over a sift's extracted records.
Args:
sift_id: The sift identifier
natural_language: The question to answer (e.g. "What is the total by client?")
| Name | Required | Description | Default |
|---|---|---|---|
| sift_id | Yes | ||
| natural_language | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It only states the purpose without revealing traits such as idempotency, side effects, error conditions, or authorization needs. This is a significant gap for a query 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?
The description is extremely concise: one sentence for purpose followed by a clear Args list. Every element is essential, and the purpose is front-loaded. No extraneous information.
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 zero schema coverage, the description covers basic usage and parameters adequately. However, it lacks behavioral context (e.g., whether the query is read-only) and does not address potential errors or limitations, which is moderate incompleteness.
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 adds meaningful parameter explanations: 'sift_id: The sift identifier' and 'natural_language: The question to answer' with an example query. This compensates well, though more detail on expected format or constraints could further help.
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 clearly states the action 'Run a natural language query' and the resource 'sift's extracted records', which distinguishes it from siblings like aggregate_sift (aggregation) and find_records (different query method). The verb is specific and the resource 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 implies usage for natural language queries on sift records but does not explicitly contrast with sibling tools or provide when-to-use/when-not-to-use guidance. No alternatives are mentioned, leaving the agent to infer based on tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Enqueue extraction for a document on a specific sift.
Args:
document_id: The document identifier
sift_id: The sift to extract with
| Name | Required | Description | Default |
|---|---|---|---|
| document_id | Yes | ||
| sift_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It hints at asynchronous behavior ('enqueue') but does not disclose side effects, permissions, or whether the operation is reversible.
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 very concise with a single sentence plus parameter breakdown. It is front-loaded and free of extraneous words, though it could be better 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 tool with two parameters and no output schema, the description lacks context such as prerequisites, error conditions, or when it should be used among many sibling tools.
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?
Parameter descriptions are minimal ('The document identifier', 'The sift to extract with'). Since schema description coverage is 0%, the description should compensate but adds little beyond parameter names.
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 ('enqueue extraction') and the resources involved ('document' and 'sift'). It distinguishes from sibling tools like 'get_extraction_status' and 'upload_document' by specifying a unique operation.
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?
No guidance is provided on when to use this tool versus alternatives, such as when extraction should be enqueued versus checking status or uploading documents.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing sift's name or instructions.
Args:
sift_id: The sift identifier
name: New name (leave empty to keep current)
instructions: New instructions (leave empty to keep current)
| Name | Required | Description | Default |
|---|---|---|---|
| sift_id | Yes | ||
| name | No | ||
| instructions | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must disclose behavior. It only states 'Update' implying mutation, but omits details on permissions, side effects, error handling, or reversibility.
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?
Short and direct, but the 'Args:' section is unformatted. The first sentence clearly states the purpose, but lacks front-loading of critical info like usage context.
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?
Adequately explains function and parameters for a simple update tool with no output schema. However, lacks behavioral transparency and error conditions, which are important for 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?
Schema description coverage is 0%, so description carries burden. It adds 'leave empty to keep current' for name and instructions, which is helpful beyond the schema defaults, but otherwise mirrors 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 verb 'update' and the resource 'sift', and lists the updatable fields (name, instructions). It distinguishes itself from sibling tools like 'create_sift' and 'delete_sift'.
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?
No guidance on when to use this tool versus alternatives like recreating the sift. The description only mentions parameter usage ('leave empty to keep current') but lacks context on prerequisites or conflicts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Upload a document to a folder. The folder is created if it doesn't exist. The document will be processed by all sifts linked to the folder.
Args:
folder_path: Target folder path (e.g. '/invoices/2025'). Created if it doesn't exist.
filename: Original filename (used for display)
content_base64: Base64-encoded file bytes
| Name | Required | Description | Default |
|---|---|---|---|
| folder_path | Yes | ||
| filename | Yes | ||
| content_base64 | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behaviors: folder creation if absent, and automatic processing by linked sifts. No annotation contradictions. Lacks details on output 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?
Four sentences, front-loaded with main purpose, then details. Every sentence adds value, 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?
Covers inputs and primary behaviors adequately. No output schema, but not required for such a tool. Minor lack of sift explanation but domain-appropriate.
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 adds essential meaning: folder_path creation behavior, filename for display, content_base64 encoding. Compensates well for schema gap.
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 'Upload a document to a folder' with specific verb and resource. Distinguishes from siblings by specifying folder creation and processing by sifts.
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 context that the document will be processed by sifts, hinting at when to use this tool over others. No explicit when-not-to-use or alternatives, but clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.8aggregate_siftcreate_siftdelete_siftfind_recordsget_extraction_statusget_folderget_record_citationsget_siftlist_folderslist_recordslist_siftsquery_siftrun_extractionupdate_siftupload_documentEach tool has a clearly distinct purpose: sift CRUD, document upload, folder management, record retrieval with two distinct methods, natural language and aggregation querying, extraction control, status checking, and citations. No overlapping functionality.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., create_sift, list_records, upload_document). No mixing of styles or inconsistent verbs.
15 tools is well-scoped for the domain of document extraction and querying. It covers sift management, document upload, folder operations, record retrieval, multiple query methods, and extraction lifecycle without being excessive.
Core workflows (create/read/update/delete sifts, upload docs, extract, query, browse folders) are covered. Minor gaps like explicit folder deletion or sift-folder unlinking are not present but may be intentionally omitted.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Query your org's data in natural language — read-only MCP access to SQL, NoSQL, files & warehouses.
Hosted MCP server for AI-driven data ops. Create apps, manage schemas, and CRUD structured data.
Turn PDFs, scans and photos into a queryable database. Invoices, CVs, receipts, in bulk.
Analytical memory for AI agents: a real Postgres queried in plain English over MCP. One command.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/sifter-ai/sifter'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
