This server provides a quality-gated, evidence-first workflow for managing coding tasks, enforcing a structured cycle: inspect, plan, implement, verify, and gate completion.
task_begin: Register a new task by recording its objective, acceptance criteria, workspace root, and optional metadata (non-goals, assumptions, constraints, allowed/protected paths) — establishing the contract before any code changes occur.
inspect_repository: Perform a deterministic, read-only inventory of the repository using ripgrep, Git, manifests, and symlink/junction scans, producing a concise snapshot of the codebase before implementation begins.
record_plan: Persist a structured, step-by-step implementation plan — including files to change, verification commands, and risks — after inspection and before any writes are permitted, enforcing plan-before-code discipline.
run_verification: Execute a single planned test, lint, build, or check command (without a shell), fingerprinting the workspace before and after to detect unexpected mutations; also allows recording evidence that no executable tests apply.
task_status: Return the append-only evidence log and current quality-gate stage for a given task (read-only).
final_gate: Evaluate the final quality gate, refusing PASS unless inspection, plan, post-change verification, diff summary, and acceptance evidence for every defined criterion are all present.
Provides a quality and safety layer for Windsurf's Cascade, enabling evidence-first development cycles with multi-model execution via Arena mode, task management, and verification gates.
Click on "Install 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., "@deepwork run deep-build on the authentication module"
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.
Documentation | Security policy | Windsurf problem matrix | Claude Code pattern study
Independent community project. Deepwork is not affiliated with or endorsed by Cognition, Windsurf, Devin, or Anthropic.
Deepwork is a max-effort quality-and-safety layer for Cascade. It makes difficult coding work follow an evidence-first cycle: contract, inspect, research, compare designs, plan, checkpoint, implement, verify, review, and only then claim completion. Windsurf's native Arena mode supplies genuine multi-model execution.
It addresses the fixable parts of the recurring problems summarized in research/problem-matrix.md: shallow repository scans, lost requirements, broad edits, repair loops, missing tests, unsupported completion claims, unsafe paths, MCP configuration risk, and weak durable state. The Claude Code pattern study records the official Anthropic mechanisms adapted into the max-effort design.
.windsurf/skills/deep-build/: the reusable @deep-build procedure and focused references, including capability-extraction.md for pushing under-provisioned model tiers.
.windsurf/workflows/deep-build.md: the 22-step /deep-build max-effort runbook.
.windsurf/workflows/deep-ultra.md: the deep route, adding hypotheses, an adversarial challenge gate, and seven review lenses.
.windsurf/workflows/deep-ultramax.md: the campaign route for the most complex multi-session work, with a twenty-step plan and a double challenge gate.
.windsurf/workflows/deep-plan.md, deep-debug.md, and deep-review.md: plan-only, reproduce-first, and review-panel routes.
.windsurf/rules/deep-build.md: short always-on behavioral constraints.
.windsurf/hooks.json: fail-closed pre-action policy and metadata-only post-action audit hooks.
src/: a thirteen-tool local deepwork MCP, four effort profiles, user-global locked state, content-fingerprinted checkpoints/reviews, constrained verifier, and hook engine.
ARCHITECTURE.md: the full system design, layer by layer.
scripts/install.ps1: idempotent global installation with ownership metadata, predecessor restoration, atomic config writes, and path-link defenses.
Related MCP server: cleanroom-mcp
For a non-trivial task, effortProfile: "max" requires:
one measurable completion condition;
three distinct repository-research lanes and eight successful unique file reads, or the complete inventory when the repository has fewer than eight files;
three architecture alternatives and no unresolved design question;
at least eight plan steps, three risks, acceptance-to-test mapping, exact file scope, and rollback;
two content-fingerprinted checkpoints, with every plan step complete in the final checkpoint;
every planned verification command against the current workspace;
correctness, tests, security, error-handling, and simplicity review passes;
only findings at confidence 80-100, with every critical/high issue resolved or disproved;
a passing final gate against current Git scope and acceptance evidence.
effortProfile: "ultra" exists for high-consequence work and for Enterprise deployments whose hosted models are weaker than the task deserves. It raises every max gate — four research lanes, four design alternatives, twelve plan steps, five risks, twelve unique reads, three checkpoints — and adds three mechanisms:
record_challenge: a mandatory adversarial round with at least three distinct attack vectors against the current design and plan. Writes stay blocked until a round is withstood; an exposed gap forces a revise verdict, a repaired plan, and a fresh challenge.
record_hypotheses: competing falsifiable hypotheses with discriminating checks. Any hypothesis left open blocks the final gate.
Seven review lenses: the five max lenses plus performance and compatibility.
task_briefing complements the deeper pipeline by rehydrating a fresh or degraded session from durable state — contract, design, plan progress, challenge/hypothesis status, verification results, and workspace-drift detection — instead of chat memory.
effortProfile: "ultramax" is the campaign tier for the most complex work: cross-cutting features, migrations, security-sensitive rewrites, and tasks expected to span multiple sessions. It raises every ultra gate again — five research lanes, five design alternatives, a twenty-step plan with eight risks, twenty unique reads, five milestone checkpoints — and requires two withstood adversarial challenge rounds before implementation: one attacking the selected design, one attacking the plan. Revising either invalidates the rounds and forces a fresh challenge. /deep-ultramax is the matching runbook and treats session boundaries as first-class: every resume starts from task_briefing, not chat memory.
An MCP can expose tools to Cascade; the documented interface cannot switch Cascade's selected Windsurf-hosted model, launch another Cascade, or start Arena. Native Arena Mode is the supported path that runs multiple Windsurf models in isolated sessions/worktrees and charges their credit multipliers additively.
Deepwork mitigates but cannot repair provider outages, editor crashes, billing policy, finite model context, Enterprise allowlists, host MCP bugs, or editor vulnerabilities. The July 8, 2026 GhostApproval disclosure demonstrated a Windsurf trust-boundary failure; check the vendor's current remediation status before relying on editor-level approval UI. Hooks cannot remove filesystem time-of-check/time-of-use races. Use low-privilege OS isolation for untrusted repositories.
The public anthropics/claude-code repository was used as an official workflow reference. Its license is all rights reserved; Deepwork does not copy Claude Code core code or claim to reproduce its private agent loop.
npm ci
npm test
node src/cli.js doctorThe automated suite covers max-effort depth gates, real stdio initialization/tool discovery, an external-project task through stdio, official hook payloads, fail-closed internal errors, hardlink/link escapes, Windows short-path aliases and PowerShell encodings, trajectory isolation, hostile command forms, repeat writes, verification-time mutations, stale same-file/untracked changes, every planned command, high-confidence review filtering, and final Git scope enforcement.
Clone and validate the package from PowerShell before opening the clone as a Windsurf workspace:
npm ci
npm run check
powershell -NoProfile -ExecutionPolicy Bypass -File .\scripts\install.ps1The installer:
stages and atomically installs a runtime under ~\.codeium\windsurf\deepwork-runtime;
installs the global skill plus /deep-build, /deep-ultra, /deep-ultramax, /deep-plan, /deep-debug, and /deep-review;
appends a bounded managed block to global_rules.md;
merges global hooks without removing existing hooks;
merges one deepwork entry into mcp_config.json;
stores an ownership manifest and predecessor backups, proves the Windows hook launcher, and runs the state/hook/stdio doctor.
Runtime task events and transcript metadata are stored outside projects under ~\.codeium\windsurf\deepwork-state, keyed by the canonical workspace. A repository .deepwork/task.md is used only when the MCP is unavailable and should remain uncommitted. Uninstall intentionally retains deepwork-state as audit/continuity data.
Enterprise administrators may still need to enable or allowlist the MCP. The runtime, skill, workflows, hooks, and MCP configuration are installed and protocol-tested locally; restart Windsurf to reload them, then confirm UI discovery under the account's live Enterprise policy.
For a normal complex task:
Initialize Git and preserve or commit the intended baseline.
Invoke /deep-build and mention @deep-build. Use /deep-ultra for the deep gated route, /deep-ultramax for the heaviest multi-session campaigns, /deep-plan for no-edit architecture, /deep-debug for a defect, or /deep-review for an independent candidate review.
Let the workflow call the thirteen deepwork tools and obey blocking hooks. Planned tests/builds run through the approval-bearing verifier; non-Deepwork MCP tools are denied unless their exact server/tool identity is deliberately allowlisted.
For deliberate multi-model use of the Enterprise credit pool:
Open the model picker and enter Arena.
Select two strong, different models currently available; avoid Adaptive when deliberate comparison is the goal.
Send the identical /deep-build @deep-build contract to both isolated candidates.
Compare research coverage, architecture, diff, tests, risks, and evidence; select a winner.
Run /deep-review with retained Arena models, resolve high-severity findings, and require deepwork.final_gate to pass.
Spend additional prompts on different research hypotheses, architecture challenge, repeated-failure diagnosis, specialized review, and finding validation - not interchangeable summaries.
Verified: contract, research, design, traceable plan, completed checkpoints, five-lens review, Git scope, acceptance evidence, every planned command, and current fingerprint passed.
Partially verified: useful work exists, but a relevant check is skipped, unavailable, or manual.
Blocked: evidence contradicts completion or a required decision/platform capability is unavailable.
If the MCP/final gate is unavailable, the maximum honest status is Partially verified.
This repository does not include a WhatsApp bot, hosted API, database, or remote Windsurf controller. The local MCP needs direct repository access, and native Arena is started manually. The documentation site explains a safe notification companion or separately built authenticated job service.
The repository is publicly visible, but no software license has been selected. Public visibility alone does not grant reuse, redistribution, or derivative-work rights.
Refuse PASS unless inspection, plan, post-change verification, diff summary, and every acceptance-evidence item exist.
| Name | Required | Description | Default |
|---|---|---|---|
| taskId | Yes | ||
| diffSummary | Yes | ||
| acceptanceEvidence | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate a mutating, non-destructive, non-idempotent operation. The description adds the key behavior that the tool will refuse unless conditions are satisfied, but does not clarify what 'refuse' means (e.g., error, boolean, side effects) or specify any additional behaviors like logging or state changes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that immediately conveys the core logic and prerequisites. Every word earns its place with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is sufficient for a simple gate check given the sibling context, but lacks details on return value, side effects, or error handling. For a tool with 3 required parameters and no output schema, more completeness would be helpful (e.g., what 'PASS' means, whether it updates task status).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates partially by naming 'diff summary' and 'acceptance-evidence items', which correspond to the diffSummary and acceptanceEvidence parameters. However, it does not explain taskId or provide any format or usage guidance beyond the schema constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific conditional verb 'Refuse PASS unless...' which clearly identifies the tool as a quality gate enforcer. It lists distinct prerequisites (inspection, plan, post-change verification, diff summary, acceptance evidence) that distinguish it from sibling tools like inspect_repository or run_verification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should be used after all prerequisites are met, but does not explicitly state when to avoid it or name alternatives. The condition is clear, but ordering guidance is inferred rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a deterministic, concise inventory using ripgrep, Git, manifests, and a symlink/junction scan.
| Name | Required | Description | Default |
|---|---|---|---|
| taskId | Yes | ||
| workspaceRoot | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds useful context by specifying the exact methods (ripgrep, Git, manifests, symlink/junction scan), which helps the agent understand the operational scope beyond what annotations convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, concise and front-loaded with the core action. It uses no filler, but could arguably be more streamlined. Still, it is efficient for its length.
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 what the tool does and how it works, but lacks parameter guidance and does not describe the output. Given the simple schema and annotations, it is minimally adequate but leaves the agent uncertain about parameter semantics and return value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, and the tool description does not mention or explain any parameters. With two parameters (taskId and workspaceRoot), the description fails to add meaning or usage context, leaving the agent to infer their purpose from names and constraints alone.
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 creates a deterministic inventory and lists the methods used (ripgrep, Git, manifests, symlink/junction scan). While it lacks specificity about what 'inventory' entails, it adequately defines the tool's purpose and distinguishes it from unrelated 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 is provided on when to use this tool versus alternatives. There is no mention of prerequisites, when not to use it, or how it complements other tools like final_gate or record_plan.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Persist a concrete plan after inspection and before any write is allowed.
| Name | Required | Description | Default |
|---|---|---|---|
| risks | No | ||
| steps | Yes | ||
| taskId | Yes | ||
| filesToChange | Yes | ||
| verificationCommands | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provide readOnlyHint, and the description does not disclose any behavioral traits beyond 'persist', such as idempotency, side effects, or authorization requirements. The description carries the burden but adds little.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise, but it lacks structure and depth. It could be expanded without becoming verbose to cover essential details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters with no schema descriptions and no output schema, the description is inadequate. It omits return behavior, parameter semantics, and important sequencing details beyond the one sentence.
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 provides no explanation of any parameter's purpose or constraints. The agent must rely solely on the parameter names and 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 tool's purpose: persisting a concrete plan after inspection and before writes. However, it does not explicitly differentiate from sibling tools like inspect_repository or task_begin, so the distinction is implied rather than stated.
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 when-to-use context ('after inspection and before any write'), but lacks explicit guidance on when not to use the tool or alternatives. The agent must infer from sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute one planned test/lint/check/build command from the untrusted repository without a shell, fingerprinting the workspace before and after. Repository-controlled code can spawn processes, access the network, or destructively mutate files; a detected mutation makes verification fail. Alternatively, record specific evidence that no executable tests apply.
| Name | Required | Description | Default |
|---|---|---|---|
| taskId | Yes | ||
| command | No | ||
| timeoutMs | No | ||
| noTestsEvidence | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond annotations by detailing fingerprinting behavior, potential for spawning processes, network access, and destructive file mutations. It clearly states that detected mutations cause verification failure, adding significant behavioral context not covered by 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?
The description is extremely concise with two sentences. The first sentence front-loads the primary action and security context; the second covers the alternative. No redundant or unnecessary 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 tool's complexity (destructive, open-world), annotations, and lack of output schema, the description covers the core concept and security implications but lacks detail on remaining parameters and return behavior. It is minimally adequate but leaves gaps for an agent to fully understand usage without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate but only partially. It implies the 'command' parameter for the action and 'noTestsEvidence' for the alternative, but does not explain 'taskId' or 'timeoutMs', nor their constraints. The meaning added is minimal and incomplete.
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 executes a planned test/lint/check/build command, with a specific verb and resource. It distinguishes itself from sibling tools by focusing on execution and includes an alternative action for no-test evidence.
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 for when to use this tool (for running verification commands from an untrusted repository) and mentions an alternative within the tool (recording no-test evidence). However, it does not explicitly compare to sibling tools like inspect_repository or final_gate, so usage guidance is good but not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Record the objective, acceptance criteria, and canonical workspace before repository work begins.
| Name | Required | Description | Default |
|---|---|---|---|
| taskId | Yes | ||
| nonGoals | No | ||
| objective | Yes | ||
| assumptions | No | ||
| constraints | No | ||
| allowedPaths | No | ||
| workspaceRoot | Yes | ||
| protectedPaths | No | ||
| acceptanceCriteria | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate non-destructive and non-idempotent behavior. The description adds that it records specific items, providing context beyond annotations. No contradictions, but does not elaborate on validation or side effects—acceptable given annotation coverage.
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?
One short sentence (12 words) that front-loads the core purpose. Every word contributes meaning; no padding 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?
With 9 parameters, no output schema, and low schema coverage, the description fails to explain many parameters (e.g., taskId, nonGoals) that are critical for correct usage. The tool's context (task initialization) is conveyed, but parameter completeness is lacking.
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 should compensate. It only explains objective, acceptanceCriteria, and workspaceRoot, leaving 6 of 9 parameters (taskId, nonGoals, assumptions, constraints, allowedPaths, protectedPaths) unexplained. Insufficient for agents to understand required inputs like taskId.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool records objective, acceptance criteria, and workspace before repository work begins, using a specific verb ('record') and resource. It distinguishes from siblings like 'final_gate' (end-of-task) and 'inspect_repository' (different action).
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 specifies 'before repository work begins,' indicating when to use. While no explicit when-not or alternatives are given, the sibling context implies this is the initial step, and 'final_gate' is the counterpart. Missing explicit exclusions or alternatives, but still clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the append-only evidence state and current quality-gate stage for a task.
| Name | Required | Description | Default |
|---|---|---|---|
| taskId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the description's mention of 'append-only' aligns but does not add new behavioral context 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?
Single sentence that is front-loaded with the verb. Efficient but omits essential parameter explanation, slightly reducing effectiveness.
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?
Missing description of the return value structure and parameter details. Annotations cover safety, but for a read operation with no output schema, the description should explain the output format.
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 the description does not document the `taskId` parameter at all, leaving the agent without guidance on valid values, format, or constraints despite the schema having a pattern.
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 returns the 'append-only evidence state' and 'current quality-gate stage' for a task, specifying the verb and resource. It distinguishes from siblings like final_gate by describing the precise components returned.
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 final_gate or inspect_repository. No indications of preconditions 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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0final_gateinspect_repositoryrecord_planrun_verificationtask_begintask_statusEach tool has a distinct purpose: starting a task, inspecting, planning, verifying, checking status, and final gating. No overlap in functionality.
All tool names follow a consistent verb_noun snake_case pattern (e.g., inspect_repository, record_plan).
6 tools is appropriate for a focused workflow covering task initiation, inspection, planning, verification, and status reporting.
The set covers the main workflow stages but lacks a tool for applying changes or modifying the repository, which may be outside scope.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
A MCP server built for developers enabling Git based project management with project and personal…
The MCP server that vets MCP servers: identity, risk grade and per-tool risk before you install.
An MCP server that provides Javelin Standalone Guardrails
Evidence-readiness MCP server: validate, audit, and score briefs, memos, and evidence packs.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/saisharan0103/windsurf-deepwork'
If you have feedback or need assistance with the MCP directory API, please join our Discord server