The first MCP server purpose-built for venture capital. Drop a company name into Claude, Cursor, or Windsurf and get a quantified investment memo in 5 minutes — not a ChatGPT summary, a real analyst-grade IMPACT-X assessment with every claim verified against evidence.
"Screen a startup called Acme Corp" → Sieve researches the company, scores it across 7 dimensions, verifies every claim, and tells you: Take the meeting or Pass.
Most VCs screen 50+ deals a month. Most of those are obvious passes — but you still spend 2-3 hours per deal on basic diligence before you know that. Sieve does that work in 5 minutes.
Capability | Details |
Investment Memo | Full analyst-grade memo with executive summary, key strengths, critical concerns, and actionable recommendation — not a ChatGPT summary |
Deal Scoring (0-140) | Quantified Sieve Score across 7 IMPACT-X dimensions — structured, repeatable, comparable across your portfolio |
Red Flag Detection | Automatically surfaces deal-breakers: founder risk, market timing issues, unsustainable unit economics, missing traction, competitive threats |
Evidence Verification | Every finding tagged as Documented, Discovered, Inferred, or Missing — cross-references pitch deck claims against real-world evidence |
Competitive Landscape | Maps competitors, identifies moat strength, evaluates defensibility and switching costs |
Financial Model Assessment | Evaluates unit economics, pricing power, revenue model viability, and path to profitability |
Market Sizing | TAM/SAM/SOM analysis with timing assessment — is the market ready? |
Team Evaluation | Founder-market fit, team completeness, domain expertise, execution track record |
Traction Analysis | Growth metrics, customer validation, revenue signals, engagement patterns |
Real-time Deal Chat | Ask follow-up questions, challenge findings, explore what-if scenarios, dig into any dimension |
Sector-Aware Analysis | Adapts benchmarks for fintech, healthtech, deeptech, climate, SaaS, consumer, and more |
Stage-Calibrated | Different expectations for pre-seed vs seed vs Series A — doesn't penalize early-stage for missing late-stage metrics |
Not a wrapper around ChatGPT. Sieve runs a structured multi-agent analysis pipeline with real-time web research, evidence verification, and domain-specific benchmarks.
We tell you what we don't know. Every finding is evidence-typed (Documented / Discovered / Inferred / Missing) so you see exactly what's verified and where the gaps are.
Repeatable framework. The same IMPACT-X methodology every time, so you can compare deals apples-to-apples across your portfolio.
Built by VCs. Not a generic AI tool adapted for investing — purpose-built for the way investors actually evaluate deals.
Dimension | What Sieve evaluates |
I — Innovators | Founding team quality, experience, domain expertise |
M — Market | Opportunity size, timing, tailwinds |
P — Product | Solution strength, differentiation, technical depth |
A — Advantage | Competitive moat, defensibility, switching costs |
C — Commerce | Business model, unit economics, pricing power |
T — Traction | Growth metrics, validation signals, customer evidence |
X — X-Factor | Unique qualities, timing advantages, intangibles |
Each dimension scores 0-20. Total Sieve Score ranges from 0-140.
Related MCP server: PitchDeck MCP Server
pip install sieve-mcpOr run directly without installing:
uvx sieve-mcpSign up free at app.sieve.arceusxventures.com
Go to Settings → copy your API key
Free tier: 2 screens/month. Pro: unlimited.
Add to your claude_desktop_config.json:
{
"mcpServers": {
"sieve": {
"command": "uvx",
"args": ["sieve-mcp"],
"env": {
"SIEVE_API_KEY": "your-api-key"
}
}
}
}claude mcp add sieve -- uvx sieve-mcp
export SIEVE_API_KEY="your-api-key"Add to your MCP settings:
{
"mcpServers": {
"sieve": {
"command": "uvx",
"args": ["sieve-mcp"],
"env": {
"SIEVE_API_KEY": "your-api-key"
}
}
}
}Tool | What it does | Read-only |
| Start a Quick Screen — pass a company name, optional website URL, pitch deck text, or description | No |
| Poll analysis progress — see which dimensions are complete and current scores | Yes |
| Get the full investment memo — Sieve Score, recommendation, strengths, concerns, evidence | Yes |
| Check how many screens you've used this billing period | Yes |
Just talk to your AI assistant naturally:
1. Screen a startup
"Run a Sieve screen on Acme Corp at acme.com"
2. Check progress (analysis takes 2-5 minutes)
"What's the status of that Sieve analysis?"
3. Get the full investment memo
"Show me the Sieve results for Acme Corp"
4. Explore the deal
"What are the red flags? Anything that should kill this deal?"
"How strong is their competitive moat? Who are the main competitors?"
"Walk me through their unit economics — is this business model viable?"
"How does the founding team stack up? Any gaps?"
"What's the market timing like? Is this too early or too late?"
"Compare this deal to the last three I screened"
5. Check your usage
"How many Sieve screens do I have left this month?"
Paste pitch deck text or founder meeting notes for maximum accuracy:
"Screen Acme Corp — here's their pitch deck text: [paste]. Also check acme.com"
Sieve cross-references every pitch deck claim against real-world evidence. When a founder says "fastest-growing in the category," Sieve checks if that's actually true.
Use case | Example prompt |
Quick pass/take meeting | "Screen this company and give me the bottom line" |
Investment memo for IC | "Generate a full investment memo I can present to my partners" |
Red flag check | "What are the deal-breakers for this startup?" |
Competitive analysis | "Who competes with this company and how defensible are they?" |
Financial viability | "Does their business model make sense? What are the unit economics?" |
Team assessment | "Evaluate the founding team — any gaps or concerns?" |
Market validation | "Is the market real? What's the TAM and timing?" |
Batch screening | "Screen these 5 startups and rank them by Sieve Score" |
Follow-up prep | "Based on this analysis, what questions should I ask the founders?" |
Portfolio comparison | "How does this deal compare to others I've screened?" |
Solo GPs screening 50+ deals/month — stop spending hours on obvious passes
Angel investors evaluating startups outside their domain — Sieve brings sector expertise
Emerging fund managers building a repeatable diligence process — consistent framework, every time
Accelerators standardizing evaluation — compare apples to apples across your cohort
Variable | Required | Default | Description |
| Yes | — | Your Sieve API key (get one free) |
| No |
| API base URL |
docker build -t sieve-mcp .
docker run -p 8080:8080 -e SIEVE_API_KEY=your-key sieve-mcp# Install locally
pip install -e .
# Run in stdio mode (for MCP clients)
sieve-mcp
# Run in HTTP mode (for remote/container deployment)
sieve-mcp httpSieve isn't just an MCP server. Use it however fits your workflow:
Web App — app.sieve.arceusxventures.com — Full experience with real-time deal chat and document upload
REST API — api.sieve.arceusxventures.com/api/docs — Integrate into custom deal flow pipelines
Android App — Screen startups on the go
Website: sieve.arceusxventures.com
Web App: app.sieve.arceusxventures.com
API Docs: api.sieve.arceusxventures.com/api/docs
Contact: hello@arceusxventures.com
MIT
Built by ArceusX Ventures — from VCs, for VCs.
List all documents in a deal's data room.
Shows what files and content have been uploaded for a deal, along with their processing status.
| Name | Required | Description | Default |
|---|---|---|---|
| deal_id | Yes | The deal ID (from sieve_deals or sieve_dataroom_add). |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint and non-destructive nature. Description adds context that it shows processing status, which is additional behavioral info beyond annotations.
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 purpose, no redundant words, efficiently conveys the tool's function.
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 output schema exists and single parameter, the description covers what the tool returns (files, content, processing status) and is complete for agent use.
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 no new meaning beyond the schema's parameter description, which is already sufficient with 100% coverage, so baseline 3.
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 'List all documents in a deal's data room' with a specific verb and resource, and differentiates from siblings like sieve_dataroom_add (add 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?
The tool's purpose is clear (listing documents), but it lacks explicit guidance on when to avoid using it or alternatives, though it's implied by the resource context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add a document to a deal's data room. Creates the deal if needed.
This is the primary way to get documents into Sieve for screening. Upload a pitch deck, financials, or any document -- then call sieve_screen to analyze everything in the data room.
Provide company_name to create a new deal (or find existing), or deal_id to add to an existing deal.
Provide exactly one content source: file_path (local file), text (raw text/markdown), or url (fetch from URL).
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | Document title (e.g. "Pitch Deck Q1 2026"). | |
| company_name | No | Company name -- creates deal if new, finds existing if not. | |
| deal_id | No | Add to an existing deal (from sieve_deals or previous sieve_dataroom_add). | |
| website_url | No | Company website URL (used when creating a new deal). | |
| document_type | No | Type: 'pitch_deck', 'financials', 'legal', or 'other'. | other |
| file_path | No | Path to a local file (PDF, DOCX, XLSX). The tool reads and uploads it. | |
| text | No | Raw text or markdown content (alternative to file). | |
| url | No | URL to fetch document from (alternative to file). |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate the tool is not read-only and not destructive, and is open-world. The description adds that it 'Creates the deal if needed,' which is a key behavioral trait, and also constrains content sources to exactly one. This goes beyond what annotations provide.
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 about six sentences, front-loading the core purpose, then providing usage context, then parameter guidance. 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 8 parameters, annotations, output schema presence, and sibling tools, the description covers the tool's purpose, side effects, parameter constraints, and integration with sieve_screen. It is sufficiently complete for an AI agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with good descriptions. The description adds semantics by explaining the interplay between company_name and deal_id, and explicitly states the exclusivity of file_path, text, and url. This adds value beyond the property 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 adds a document to a deal's data room and can create the deal if needed. It uses specific verbs and resources ('Add a document', 'creates the deal') and distinguishes from siblings like sieve_screen which analyzes, and sieve_deals which lists deals.
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 says 'This is the primary way to get documents into Sieve for screening' and 'then call sieve_screen to analyze everything in the data room,' providing clear context for when to use this tool and a follow-up action. It doesn't explicitly list exclusions, but the guidance is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List deals in your Sieve pipeline.
Search by company name or list all deals. Returns deal metadata including Sieve scores for screened deals.
| Name | Required | Description | Default |
|---|---|---|---|
| search | No | Search by company name (partial match). Empty returns all. | |
| limit | No | Maximum results to return (1-100, default 20). |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already note readOnly and non-destructive; description adds that it returns deal metadata with Sieve scores, which is useful beyond schema. 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?
Two sentences, front-loaded purpose, no filler. 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?
Simple list tool with 2 params, rich annotations, and output schema present. Description covers use and return content adequately.
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 covers both parameters with full descriptions (100% coverage). Description reiterates search behavior (partial match, empty returns all) but adds no new detail 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?
Clearly states 'List deals in your Sieve pipeline,' specifies optional company name search, and distinguishes from sibling tools like sieve_dataroom, sieve_memo, etc. Describes returns including Sieve scores.
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?
Indicates when to use (list/search deals) and scope (company name or all), but lacks explicit when-not or alternatives relative to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get or generate an investment memo for a deal.
If generate=false (default), retrieves the existing memo. If generate=true, creates a new memo (~15-30 seconds). Requires a completed screen.
| Name | Required | Description | Default |
|---|---|---|---|
| deal_id | Yes | The deal ID (from sieve_deals or sieve_screen). | |
| generate | No | Set to true to generate a new memo. | |
| memo_type | No | 'internal' (IC-facing, full risks) or 'external' (founder-facing). Default: internal. | internal |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false, so mutation is expected. Description adds time estimate (~15-30 seconds) for generation and precondition (completed screen), which are valuable beyond annotations. 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 short (4 sentences), front-loaded with purpose, and efficiently covers key behavior. Slightly verbose in repetition but overall good conciseness.
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 presence of an output schema, the description adequately covers get vs generate, timing, and precondition. It does not discuss errors or edge cases, but for a simple tool this is sufficient.
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?
Input schema has 100% coverage with descriptions for all three parameters. Description adds minimal extra context (deal_id source, memo_type definitions) but mostly reiterates schema info, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets or generates an investment memo for a deal, with specific verbs and resource. It distinguishes from siblings by focusing on memo retrieval/generation, which is unique among tools like sieve_dataroom, sieve_deals, etc.
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 clear context on when to use generate=false vs generate=true and mentions the prerequisite 'Requires a completed screen'. However, it does not explicitly state when not to use this tool or suggest alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the full results of a completed Sieve analysis.
Returns the Sieve Score (0-140), meeting decision (Take Meeting/Pass/ Need More Info), executive summary, key strengths, and key concerns.
| Name | Required | Description | Default |
|---|---|---|---|
| deal_id | Yes | The deal ID returned by sieve_screen. | |
| sections | No | Comma-separated filter (e.g. 'summary,strengths,concerns'). Options: summary, profiles, findings, questions, strengths, concerns. Empty returns everything. Score and decision are always included. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and destructiveHint=false. The description adds value by detailing the return values (score, decision, summary, etc.) and the effect of the 'sections' parameter. However, it could mention error handling for invalid deal_ids.
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 two sentences long, front-loaded with purpose, and efficiently lists outputs without redundancy. 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?
For a simple retrieval tool with an output schema, the description covers purpose, returns, and parameter usage. It could be more explicit about the dependency on a valid deal_id from sieve_screen, but overall it sufficiently informs the agent.
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?
Input schema has 100% coverage with descriptions for both parameters. The description does not add new information about parameters beyond what the schema provides, but it contextualizes the 'sections' parameter by listing filter options.
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 the full results of a completed Sieve analysis.' It lists specific outputs (Sieve Score, meeting decision, executive summary, etc.), making it distinct from sibling tools like sieve_screen which starts the analysis.
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 the tool should be used after a completed Sieve analysis, but it does not explicitly state when to use it versus alternatives (e.g., sieve_screen) or provide exclusions. No direct guidance on prerequisites or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a Sieve IMPACT-X Quick Screen on a startup.
Analyzes the company across 7 dimensions (Innovators, Market, Product, Advantage, Commerce, Traction, X-Factor) and returns an analysis ID. Takes 2-5 minutes to complete. Upserts -- if the company was previously screened, returns the existing deal (set confirm=true to re-screen).
Two ways to use:
v3 (recommended): First add documents with sieve_dataroom_add, then call sieve_screen(deal_id=...) to analyze everything in the data room.
v2 (legacy): Call sieve_screen(company_name=..., website_url=...) directly. At least one of website_url or pitch_deck_text is required in this mode.
| Name | Required | Description | Default |
|---|---|---|---|
| company_name | No | Name of the startup to screen (v2 flow, or to create new deal). | |
| deal_id | No | Screen an existing deal by ID (v3 flow -- use after sieve_dataroom_add). | |
| website_url | No | Company website URL (v2 flow). | |
| pitch_deck_text | No | Extracted pitch deck text (v2 flow). | |
| description | No | Brief company description (optional). | |
| confirm | No | Set to true to re-screen an existing deal. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false, destructiveHint=false, and openWorldHint=true. The description adds behavioral context: the tool takes 2-5 minutes to complete, and it upserts (returns existing deal if previously screened unless confirm=true). This goes beyond the annotations, though it does not detail the exact impacts or error states. No contradiction found.
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 yet comprehensive, with a clear structure: introduction, timing and upsert behavior, then two usage modes. Every sentence adds value, and the formatting (bullets, indentation) aids readability. No unnecessary words or 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 tool's complexity (two modes, 6 parameters, output schema exists), the description is largely complete. It covers workflows, parameter requirements, timing, and upsert behavior. The output schema is not provided, but its existence is noted, so the description need not detail return values. A slight shortcoming is not mentioning what happens if both flows are used simultaneously (though schema might enforce), but overall it is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds meaning by explaining how parameters relate to the two workflows (e.g., deal_id for v3, company_name/website_url for v2) and specifies the requirement that at least one of website_url or pitch_deck_text is needed in v2. This contextualizes parameters beyond the schema's individual 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 a Sieve IMPACT-X Quick Screen on a startup.' It specifies the 7 dimensions analyzed and that it returns an analysis ID. It also distinguishes two distinct workflows (v3 and v2), making the purpose and resource 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 explicitly provides usage guidelines: when to use v3 (after sieve_dataroom_add) vs v2 (directly with company_name/website_url), and notes that at least one of website_url or pitch_deck_text is required in v2. It also explains the behavior of the 'confirm' parameter for re-screening. This gives clear when-to-use guidance and differentiates from sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check the progress of a Sieve analysis.
Returns which IMPACT-X dimensions are complete with their scores, overall progress percentage, and current phase.
| Name | Required | Description | Default |
|---|---|---|---|
| deal_id | Yes | The deal ID returned by sieve_screen. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, indicating a safe read. The description adds behavioral insight by detailing the specific return values (dimensions, scores, progress percentage, current phase), which goes beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the purpose, followed by specifics. No redundant information. 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 that an output schema exists, the description does not need to detail return format. It provides a high-level summary of returns, input is clear, annotations cover safety, and sibling tools are listed. Complete for a progress-checking 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?
The input schema has full coverage (100%) for the single parameter deal_id, with a clear description. The tool description does not add additional meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Check' and the resource 'progress of a Sieve analysis', and lists specific return values (dimensions, scores, percentage, phase). This distinguishes it from siblings like sieve_screen or sieve_results.
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 checking progress after sieve_screen, but does not explicitly state when to use versus alternatives or provide exclusions. Sibling names provide indirect context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check your Sieve API usage for the current billing period.
Shows screens used, monthly limit, tier, and organization name.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and non-destructive behavior. The description adds specifics about what data is returned (screens used, monthly limit, tier, org name), providing useful context beyond annotations.
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 with no wasted words, front-loaded with the main purpose. Highly concise and well-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 no-parameter tool with an output schema, the description adequately covers purpose and returned data. No gaps identified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, so the description does not need to document them. Baseline score of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks Sieve API usage for the current billing period and lists specific data shown (screens, limit, tier, org name), distinguishing it from 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?
The description implies usage for checking billing usage but does not provide explicit guidance on when to use vs alternatives or when not to use.
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.
sieve_dataroom1 field changedInput schema / properties / deal_id / descriptionAdded value: +"The deal ID (from sieve_deals or sieve_dataroom_add)."sieve_dataroom_add8 fields changedInput schema / properties / company_name / descriptionAdded value: +"Company name -- creates deal if new, finds existing if not."Input schema / properties / deal_id / descriptionAdded value: +"Add to an existing deal (from sieve_deals or previous sieve_dataroom_add)."Input schema / properties / document_type / descriptionAdded value: +"Type: 'pitch_deck', 'financials', 'legal', or 'other'."Input schema / properties / file_path / descriptionAdded value: +"Path to a local file (PDF, DOCX, XLSX). The tool reads and uploads it."Input schema / properties / text / descriptionAdded value: +"Raw text or markdown content (alternative to file)."Input schema / properties / title / descriptionAdded value: +"Document title (e.g. \"Pitch Deck Q1 2026\")."Input schema / properties / url / descriptionAdded value: +"URL to fetch document from (alternative to file)."Input schema / properties / website_url / descriptionAdded value: +"Company website URL (used when creating a new deal)."sieve_deals2 fields changedInput schema / properties / limit / descriptionAdded value: +"Maximum results to return (1-100, default 20)."Input schema / properties / search / descriptionAdded value: +"Search by company name (partial match). Empty returns all."sieve_memo3 fields changedInput schema / properties / deal_id / descriptionAdded value: +"The deal ID (from sieve_deals or sieve_screen)."Input schema / properties / generate / descriptionAdded value: +"Set to true to generate a new memo."Input schema / properties / memo_type / descriptionAdded value: +"'internal' (IC-facing, full risks) or 'external' (founder-facing). Default: internal."sieve_results2 fields changedInput schema / properties / deal_id / descriptionAdded value: +"The deal ID returned by sieve_screen."Input schema / properties / sections / descriptionAdded value: +"Comma-separated filter (e.g. 'summary,strengths,concerns').\n Options: summary, profiles, findings, questions, strengths, concerns.\n Empty returns everything. Score and decision are always included."sieve_screen6 fields changedInput schema / properties / company_name / descriptionAdded value: +"Name of the startup to screen (v2 flow, or to create new deal)."Input schema / properties / confirm / descriptionAdded value: +"Set to true to re-screen an existing deal."Input schema / properties / deal_id / descriptionAdded value: +"Screen an existing deal by ID (v3 flow -- use after sieve_dataroom_add)."Input schema / properties / description / descriptionAdded value: +"Brief company description (optional)."Input schema / properties / pitch_deck_text / descriptionAdded value: +"Extracted pitch deck text (v2 flow)."Input schema / properties / website_url / descriptionAdded value: +"Company website URL (v2 flow)."sieve_status1 field changedInput schema / properties / deal_id / descriptionAdded value: +"The deal ID returned by sieve_screen."v0.3.0sieve_dataroomsieve_dataroom_addsieve_dealssieve_memosieve_resultssieve_screensieve_statussieve_usageEach tool has a clearly distinct purpose: listing documents, adding documents, listing deals, running screens, checking status, retrieving results, getting memos, and checking usage. No two tools overlap in functionality.
All tools share the 'sieve_' prefix, but naming patterns are mixed: some are plain nouns (e.g., sieve_dataroom, sieve_deals) while others use verb_noun (e.g., sieve_dataroom_add). This minor inconsistency prevents a perfect score.
With 8 tools, the set covers the full document screening lifecycle without unnecessary duplication. Each tool serves a necessary role, and the count feels appropriate for the domain.
The tool set covers the primary workflow: add documents, screen, check status, get results, and generate memos. However, it lacks update or delete operations for documents or deals, which could be useful but are not critical for core use.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Pre-diligence AI for founders, investors, and firms — multi-agent pitch analysis and deal flow.
CRM for VC fundraising. Pipeline, Gmail drafts, deck signals, VC intel — from your AI.
AI-powered board deck generation and governance reporting for private equity firms.
Search and act on your VC firm's deal pipeline: deals, notes, tasks, analyst assignment.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/lmwharton/sieve-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
