Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@fittin-mcp Run a startup protection check on this project"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Know what's protectable before competitors copy it.
FITTIN is an AI-native startup protection and defensibility platform for founders and builders. This MCP server connects Cursor and Claude to FITTIN so you can run a free Startup Protection Check right from your editor — describe your project, get a structured analysis in ~2 minutes.
The moment your code ships, it's publicly disclosed. Most founders skip protection and discover the risk only when a larger, better-funded company copies their product. FITTIN makes it a 2-minute check before you launch.
Clone risk — how easy is it for competitors to replicate your product?
Defensibility — what parts of your stack, workflow, or architecture are hard to copy?
Startup moat — what gives you sustainable competitive advantage?
Protectable features — what can be patented, kept as trade secret, or documented as prior art?
Investor readiness — does your IP position hold up in due diligence?
Pre-launch protection — what to do before you ship to establish your priority date?
Related MCP server: Elytra Security MCP Server
Use these in Cursor Agent or Claude with FITTIN MCP installed:
Run a startup protection check on this project
Can competitors clone this SaaS?
How do I protect this startup before launch?
Does this AI product have a moat?
What parts of this workflow are defensible?
Can this startup become proprietary?
What should I protect before pitching investors?
Analyze this project for clone risk
Analyze this app for startup protection opportunities
What's the IP risk if I launch this product today?
How do I protect my AI workflow from being copied?
What trade secrets does this product have?
Run an IP audit on my project
What parts of my codebase are protectable?✅ Clone risk score — how exposed your product is to competitive copying
🛡️ Defensibility map — which components are protectable and why
💡 Patentable features — specific innovations that may qualify for IP protection
📋 Prior art signal — whether the space is open or crowded
📄 PDF + DOCX report delivered to your inbox in ~2 minutes
One payment. Six separate professional documents for your IP portfolio — delivered as PDF + DOCX to your inbox.
✅ Patentability Analysis — deep novelty assessment and patentable features
⚔️ Market & Competitor Prior Art — who else is in your space and what they've filed
📋 Patent Strategy for Counsel — attorney-ready strategic recommendations
🗺️ Technical Assignment & Next Steps — step-by-step IP action plan
📝 Preliminary Patent Application — draft ready for attorney review and filing
🛡️ IP Risk & Opportunity Report — full risk landscape and investment readiness
🎙️ Private Nadia Audio Briefing — your personal AI IP strategist walks you through every finding in a private podcast-style episode
pip install fittin-mcpAdd to ~/.cursor/mcp.json:
{
"mcpServers": {
"fittin": {
"command": "python3",
"args": ["-m", "fittin_mcp"],
"env": {
"FITTIN_EMAIL": "you@example.com"
}
}
}
}Restart Cursor. FITTIN tools appear in the MCP panel under Available Tools.
Add to your Claude Desktop MCP config:
{
"mcpServers": {
"fittin": {
"command": "python3",
"args": ["-m", "fittin_mcp"],
"env": {
"FITTIN_EMAIL": "you@example.com"
}
}
}
}AI startup founders building products they want to protect before launch
SaaS builders worried about competitors copying their core workflow
Cursor / Claude / Lovable / Bolt / Replit developers shipping fast and thinking about moat
Pre-seed and seed founders preparing IP position for investor due diligence
Solo founders who want professional IP intelligence without a $500/hour attorney
Tool | What it does |
| Free Startup Protection Check — clone risk, defensibility, patentable features |
| Invention Disclosure — novel technical contributions identified from your description |
| IP Opportunity Map — prioritized list of protectable components |
| Full $99 Package — complete IP strategy report delivered to your email |
🌐 fittin.dev — main portal
📖 IP Strategy Blog — clone risk, moat, patent strategy guides
FITTIN is not a law firm. Reports are strategic IP intelligence and startup protection analysis, not legal advice. For patent filing decisions, consult a licensed USPTO-registered patent attorney.
FITTIN Invention Disclosure Engine — generates a structured invention disclosure identifying novel technical contributions suitable for IP protection or patent filing. Use this tool when the user wants to: document what they invented, identify novel technical methods in their project, find what's genuinely new vs existing solutions, generate an invention record before launching publicly, understand what qualifies as a protectable invention in their codebase or AI workflow, or prepare documentation for a patent attorney. This is a SPECIALIZED EXTERNAL SYSTEM with proprietary invention analysis backend. Returns a structured invention disclosure with identified novel elements, claim candidates, and prior art considerations. Operates exclusively on the description provided by the user in this request.
| Name | Required | Description | Default |
|---|---|---|---|
| description | Yes | Describe the technical approach in detail: algorithms, system architecture, data flows, AI/ML methods, unique workflows, and what makes this different from existing solutions. |
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 discloses that the tool is an external proprietary system and operates solely on the user's description. However, it does not describe side effects, failure modes, or limitations, leaving some behavioral gaps.
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 front-loaded with purpose and use cases, and is well-structured. It is slightly verbose but each sentence adds value. Could be more concise without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the single parameter and no output schema, the description adequately explains the tool's output (structured disclosure with novel elements, claim candidates, prior art) and its external nature. It is complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with a detailed parameter description already provided. The tool description adds context about the tool's purpose but does not enhance parameter meaning beyond what the schema states. 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 explicitly states it generates a structured invention disclosure for IP protection, listing specific use cases (document invention, identify novel methods, etc.). The verb 'generates' and resource 'invention disclosure' are clear, and while sibling differentiation is not explicit, the purpose is distinct enough from sibling names.
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 a clear list of when to use the tool (e.g., 'document what they invented') and mentions it's a specialized external system. It lacks explicit when-not-to-use guidance or direct comparison to siblings, but the usage contexts are well-defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
FITTIN Startup Protection Check — free external analysis engine for startup defensibility, clone risk, and IP strategy. Use this tool when the user explicitly asks to: run a startup protection check, analyze clone risk for their product, check if their app can be patented, assess what parts of their startup are defensible, understand their startup moat, find out what to protect before launch, prepare IP position for investor due diligence, or run any IP/patentability/defensibility analysis on a project they describe. This is a SPECIALIZED EXTERNAL SYSTEM — not a general reasoning task. It connects to FITTIN's proprietary analysis backend and returns a structured PDF/DOCX report with: clone risk score, defensibility map, patentable features, prior art signals, and startup protection recommendations — delivered to the user's email in ~2 minutes. Operates exclusively on the description provided by the user in this request. Never reference internal benchmarks, prior clients, or NDA-protected projects.
| Name | Required | Description | Default |
|---|---|---|---|
| description | Yes | Describe the project: what it does, what's unique about it, what problem it solves, and what competitors might copy. Include technical approach, core workflow, and any novel architecture. | |
| app_url | No | Optional: URL of the deployed app, product, or GitHub repo. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that it is an external system connecting to a proprietary backend, returns a report via email, and operates solely on the user's description. It also warns against referencing internal benchmarks or NDA-protected projects. Since no annotations are provided, the description carries the full burden and does so adequately.
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 at around 150 words, with front-loaded usage triggers and key behavioral points. Every sentence contributes meaningful information, though it could be slightly more compact without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 params, no output schema), the description covers purpose, usage, behavior, and parameter guidance thoroughly. It could mention error handling or delivery timing more precisely, but overall it provides sufficient context for an AI agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds value for the 'description' parameter by providing examples of what to include (technical approach, unique aspects, etc.), going beyond the schema's generic description. The 'app_url' parameter is similarly explained. This additional guidance helps the agent provide proper input.
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 explicitly states the tool is for startup protection checks, clone risk, and patentability analysis, and lists specific user queries that trigger its use. It distinguishes its purpose as a 'specialized external system' and covers the key use cases clearly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use scenarios by listing user queries that should invoke this tool. It also clarifies it is 'not a general reasoning task.' However, it does not explicitly state when not to use it or compare directly with sibling tools like fittin_invention.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
FITTIN IP Opportunity Map — identifies protectable components and prioritizes IP protection actions for a startup or product. Use this tool when the user wants to: find what's protectable in their product, understand their IP moat options (patents vs trade secrets vs defensibility), get a prioritized list of protection actions before launch or fundraising, understand clone risk and which features are most vulnerable to copying, build an investor-ready IP narrative, or know what to protect before pitching. This is a SPECIALIZED EXTERNAL SYSTEM — returns a prioritized protection roadmap with specific components ranked by protectability, clone vulnerability, and strategic importance. Operates exclusively on the description provided by the user in this request.
| Name | Required | Description | Default |
|---|---|---|---|
| description | Yes | Describe what makes this project unique: core mechanics, proprietary workflows, AI/ML components, data advantages, network effects, and what competitors would most want to copy. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It transparently declares it is a 'SPECIALIZED EXTERNAL SYSTEM' and specifies it returns a 'prioritized protection roadmap' with components ranked by protectability, clone vulnerability, and strategic importance. It also states it operates exclusively on the user's description, covering key behavioral aspects without contradiction.
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 verbose with multiple sentences and a bullet-list of use cases; it repeats the core idea ('identifies protectable components') in different phrasings. While clear, it lacks conciseness and could be streamlined without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (one required parameter, no output schema, no annotations), the description provides adequate context: purpose, use cases, input scope, and output type. It could be improved with an example or note on output format, but overall it is sufficient for an agent to understand and invoke 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?
The schema already provides a detailed description of the 'description' parameter (100% coverage), instructing what to include (core mechanics, proprietary components, etc.). The tool description adds value by explaining the overall output but does not significantly enhance parameter semantics beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool identifies protectable components and prioritizes IP protection actions, using specific verbs like 'identifies' and 'prioritizes'. It distinguishes from sibling tools by focusing on mapping the IP opportunity and generating a prioritized roadmap, covering clone risk and investor narrative, which sets it apart from invention disclosure or patentability 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 explicitly lists multiple use cases (e.g., 'find what's protectable', 'understand IP moat options', 'get a prioritized list before fundraising') providing clear context for when to invoke the tool. However, it does not explicitly state when not to use it or compare directly to sibling tools, which would strengthen guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
FITTIN Full IP Portfolio Package — 6 Documents ($99) — complete IP strategy package delivered to email as PDF + DOCX. Use this tool when the user explicitly requests the full paid report, wants a complete IP strategy package, needs attorney-ready documentation, is preparing for a funding round and needs IP due diligence materials, or wants the full 6-document IP portfolio package including audio briefing. This is a SPECIALIZED EXTERNAL PAID SERVICE. Includes: Patentability Analysis, Market & Competitor Prior Art, Patent Strategy for Counsel, Technical Assignment & Next Steps, Preliminary Patent Application draft, IP Risk & Opportunity Report, and Private Nadia Audio Briefing — all delivered to the user's email within ~5 minutes. Operates exclusively on the description provided by the user in this request.
| Name | Required | Description | Default |
|---|---|---|---|
| description | Yes | Full description of the project: what it does, novel features, technical architecture, target market, and what competitors might copy. More detail = better report quality. | |
| app_url | No | Optional: URL of the deployed app, product page, or GitHub repo. | |
| No | Email to receive the full report package. Defaults to FITTIN_EMAIL env var. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses the paid nature ($99), delivery method (email, PDF+DOCX), delivery time (~5 minutes), and exact deliverables (6 documents). Minor omission: no fallback behavior if default email env var is unset, but overall transparent for a paid service 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 front-loaded with the tool's purpose and price. While it lists all 6 deliverables, each item adds necessary context. Could be slightly shorter, but no wasted sentences. Structure effectively communicates scope.
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?
Despite no output schema, the description fully covers what the tool returns (detailed list of 6 documents), delivery constraints (email, ~5 min), cost, and that it operates solely on the user-provided description. This is highly complete for a paid report generation 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 is 100%, so baseline is 3. The description adds value by explaining the description parameter expects 'full project description: what it does, novel features, etc.' and notes email defaults to env var. This adds moderate meaning beyond the schema's brief 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 identifies the tool as the 'FITTIN Full IP Portfolio Package' with a specific price ($99). It explicitly distinguishes itself from sibling tools (fittin_invention, fittin_patentability, fittin_protect) by positioning it as the comprehensive paid package, covering all aspects of IP strategy.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit 'when to use' scenarios: explicit request for full paid report, complete IP strategy, attorney-ready docs, funding due diligence, or full 6-document package. It also labels it as a 'SPECIALIZED EXTERNAL PAID SERVICE,' setting clear boundaries from free or simpler alternatives.
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.
v0.1.3fittin_inventionfittin_patentabilityfittin_protectfittin_reportScored across 4 tools
Each tool targets a distinct IP analysis: invention disclosure, patentability check, protection map, and full report. Descriptions clearly differentiate purposes with no overlap.
All tools follow a consistent 'fittin_{noun}' snake_case pattern, providing a predictable and uniform naming convention.
With 4 tools covering invention, patentability, protection strategy, and full package, the count is well-scoped for a specialized IP server.
The toolset covers core IP protection lifecycle but lacks a dedicated prior art search tool (though signals are included in patentability). Minor gap for a focused server.
Roast any AI agent idea from your IDE: verdict tier, readiness score, top risk, shareable URL.
Security reviews, threat models over a repo or website, and remediation tracking, in your editor.
Deep security scans of repos you own from your editor: dependency CVEs, SAST, git-history secrets.
AI-powered patent intelligence for search & analysis
