How do I use ContextECF MCP?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@ContextECF MCP Assemble context for the P1 escalation before I draft the incident brief." 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.

ContextECF MCP

Official

by Intelligent-Context-AI-Inc

Overview Schema Source Related Servers Discussions Admin

TypeScript

Hybrid

ContextECF MCP

@intelligentcontext/contextecf-mcp is a secure gateway for AI memory. It lets external agent hosts request verifiable, policy-governed ContextPackages without direct database access, raw credentials, Fabric internals, or customer content.

Canonical public demo: https://mcp.enterprisecontextfabric.com

Hosted MCP endpoint: https://mcp.enterprisecontextfabric.com/mcp

Claude connector guide: CLAUDE_CONNECTOR.md

Docker guide: DOCKER.md

Tools

context_assemble: Assemble a schema-valid, governed ContextPackage from the Fabric public API.
context_explain: Explain why a ContextPackage was assembled.
context_evidence: Return metadata for an evidence reference without exposing source bodies.
context_status: Check facade readiness.
context_feedback: Submit metadata-only usefulness feedback.

Related MCP server: Lemma Oracle MCP Server

MCP Request Shape

MCP hosts call tools through standard JSON-RPC. The outer request shape is standardized by MCP; the arguments object is the ContextECF tool contract:

{
  "jsonrpc": "2.0",
  "id": "req-8921a-mcp",
  "method": "tools/call",
  "params": {
    "name": "context_assemble",
    "arguments": {
      "packId": "support-sla-p1",
      "intentKind": "triage_sla_breach",
      "userRequest": "A P1 customer escalation just came in. Assemble ticket, SLA, customer account, knowledge-base, and prior conversation context before drafting an internal incident brief.",
      "timeWindow": {
        "lookbackDays": 30,
        "lookaheadDays": 7
      },
      "sourceCapabilities": ["ticket", "sla", "customer_record", "knowledge_base", "conversation"],
      "modeId": "synthetic-support-sla-p1",
      "responseShape": "panel_sections"
    }
  }
}

The facade validates those arguments and, in live mode, forwards the same governed public contract to POST /public/v1/context/assemble with the configured tenant/auth headers. The public launch demo runs the same tool contract against visibly synthetic data only.

packId and intentKind are the public explanation handles for the package. modeId is accepted for compatibility as an opaque assembly profile id; callers should not treat it as a business taxonomy, UI mode, or stable customer workflow name.

Use ContextECF With Claude

ContextECF Claude Connector is the Claude-facing distribution of contextecfMCP. It lets Claude call a remote MCP connector and receive governed ContextPackages, not raw database access.

Default positioning:

Give Claude governed enterprise memory without giving it direct database access.

Launch tiers:

Remote MCP connector: primary path for Claude web, mobile, Desktop, Cowork, and Claude Code where custom remote MCP connectors are available.
Claude Desktop local MCP: private proof-of-concept, local demo, appliance-style trial, or teams not ready for remote connector authorization.
Claude Code plugin: later developer-focused package for CodeLedger, architecture decisions, incident context, and repository memory.

Claude prompts:

Support: Claude, assemble context for this P1 escalation before I draft the incident brief.
Sales: Claude, prepare me for this strategic renewal call.
Productivity: Claude, brief me for the cross-functional budget review.
NetOps: Claude, assemble service degradation context before I start triage.
Developer later track: Claude, retrieve governed repository context before suggesting a code change.

See CLAUDE_CONNECTOR.md for individual setup, enterprise admin rollout, local Claude Desktop configuration, and the security FAQ.

Configuration

Live mode uses environment variables only:

CONTEXTECF_ENDPOINT=https://fabric.example.com \
CONTEXTECF_TENANT_ID=tenant_123 \
CONTEXTECF_AUTH_MODE=oidc \
CONTEXTECF_ACCESS_TOKEN="$TOKEN" \
npx @intelligentcontext/contextecf-mcp

API-client mode exchanges existing Agent API credentials:

CONTEXTECF_ENDPOINT=https://fabric.example.com \
CONTEXTECF_TENANT_ID=tenant_123 \
CONTEXTECF_AUTH_MODE=api_key \
CONTEXTECF_CLIENT_ID="$CLIENT_ID" \
CONTEXTECF_CLIENT_SECRET="$CLIENT_SECRET" \
npx @intelligentcontext/contextecf-mcp

Demo mode uses bundled synthetic data and makes no network calls:

npx @intelligentcontext/contextecf-mcp --demo

Hosted Streamable HTTP mode serves /mcp plus /health:

CONTEXTECF_MCP_TRANSPORT=http \
CONTEXTECF_MCP_PORT=3001 \
CONTEXTECF_MCP_PATH=/mcp \
npx @intelligentcontext/contextecf-mcp --demo --http

Docker

The Docker image defaults to synthetic demo mode over stdio for Docker MCP Toolkit compatibility:

docker build -t intelligentcontext/contextecf-mcp:local .
docker run --rm -i intelligentcontext/contextecf-mcp:local

For local HTTP testing:

docker compose up --build
curl http://127.0.0.1:3001/health

The Docker-facing positioning is:

Give AI agents governed enterprise context for the task at hand without giving them direct database access.

See DOCKER.md for Docker Hub copy, Docker MCP Toolkit positioning, local demo commands, private Fabric mode, and the demo-to-private-deployment path.

Synthetic Live Demo

The public demo is no-login, synthetic, read-only, and metadata-only at the evidence layer. It demonstrates the same promise as the product landing page: AI agents get a governed assembled-context preview and the evidence references they are authorized to see, while excluded sources and receipt provenance stay visible.

It ships four first-path scenarios:

Support: P1 customer escalation context across ticket, SLA, account, knowledge-base, and prior conversation metadata.
Sales: strategic renewal call context across opportunity, account history, stakeholders, meetings, and email-thread metadata.
Productivity: executive budget review context across calendar, docs, tasks, decisions, and open commitments.
NetOps: service degradation context across metrics, ServiceNow incident history, topology, runbook, and recent change metadata.

Each scenario returns a synthetic assembled-context preview, selected sources, excluded source reason codes, sufficiency, metadata-only evidence references, gap annotations, and receipt-style proof artifacts.

How Context Assembly Works

This is the public, non-IP description of the assembly path. It explains step and outcome without exposing proprietary algorithms, ranking weights, connector internals, scoring formulas, or private Fabric runtime details.

Stage	Outcome
Request intake	The MCP `context_assemble` call becomes a bounded context intent for the selected use case.
Mode profile selection	The intent is matched to an opaque assembly profile for the job-to-be-done.
Identity and policy check	The package is scoped to the persona, assembly profile, request window, and allowed source classes.
Source selection	Only relevant enterprise source categories are selected before assembly begins.
Evidence assembly	Authorized signals become evidence references instead of raw database or document dumps.
Sufficiency evaluation	The response declares whether the context is sufficient, partial, or insufficient for the request.
Exclusion annotation	Denied or irrelevant sources are listed with reason codes before the model can use them.
Receipt generation	The package carries a receipt-style proof artifact for provenance and tamper checks.
MCP delivery	The agent receives a schema-valid ContextPackage through the standardized MCP response.

The Docker demo uses four visible synthetic mode profiles: support, sales, productivity, and netops. The broader private-deployment pattern is that enterprises can define governed modes for repeatable jobs-to-be-done, then expose those modes through the same MCP tool contract instead of connecting every agent directly to every source system.

Boundary

This package is intentionally a thin translation layer. It does not import ContextECF private engine, boundary, scoring, learning, or retrieval internals. All live behavior comes from /public/v1/context/* over HTTPS.

Returned evidence references are metadata-only. Demo packages can include a synthetic assembled-context preview, but they do not return raw prompts, responses, customer documents, credentials, embeddings, private scoring recipes, or proprietary context-engineering internals. The public endpoint stops at recommend and structurally rejects command-capsule-shaped requests.

Available Tools

5 tools

context_assembleB

Read-only

Assemble a read-only governed ContextECF context package with a synthetic assembled-context preview, selected sources, exclusions, metadata-only evidence references, sufficiency, gaps, and receipt metadata.

ParametersJSON Schema

Name	Required	Description
`modeId`	No	Optional opaque assembly profile id. The public explanation surface is packId plus intentKind.
`packId`	Yes
`intentKind`	Yes
`timeWindow`	Yes
`userRequest`	Yes
`responseShape`	No
`sourceCapabilities`	Yes

TDQS

B3.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the readOnlyHint=true annotation, the description adds meaningful behavioral traits: the result is a 'synthetic assembled-context preview' with 'metadata-only evidence references', indicating the output is not raw evidence or full data. It also lists exclusions/sufficiency/gaps, which helps set expectations about what the package contains. No contradiction with the annotations appears.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single dense sentence with the main verb and object front-loaded. The long list of package components is somewhat heavy, but each item adds useful information about the assembly output; the structure is still efficient for the scope.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema belies the need for the description to explain the return envelope, and it only loosely lists contents. The seven-parameter nested input schema is left largely unexplained, and no guidance is given for how the output shape or synthetic preview behaves. The description provides a high-level inventory but not enough operational detail for an agent to call the tool correctly without further assumptions.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 14%, and the description does not compensate. It references 'selected sources, exclusions' but does not explain how they map to parameters like sourceCapabilities or responseShape, nor does it clarify the required packId, intentKind, userRequest, and timeWindow semantics beyond their names.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb ('Assemble') and a clear resource ('a read-only governed ContextECF context package'), then enumerates the package contents: preview, sources, exclusions, evidence references, sufficiency, gaps, and receipt metadata. This distinguishes it from sibling tools like context_explain or context_evidence, which clearly serve different purposes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives no explicit guidance about when to use this tool versus the sibling tools (context_explain, context_evidence, context_status, context_feedback). There is no 'use when' or 'use instead' language, so an agent must infer routing entirely from the name and resource wording.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

context_evidenceA

Read-only

Return metadata for a public evidence reference.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.5/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds the useful context that this targets public evidence references, but it does not disclose return format or any edge-case behavior; this is acceptable given 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

One concise sentence, front-loaded with the action and resource, with no filler or redundant information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter, read-only metadata tool with annotations, the description is mostly sufficient. It could clarify what qualifies as an 'evidence reference' or name a possible input, but no critical invocation detail is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters and schema description coverage is 100%, so there is no parameter burden for the description to carry. Baseline 4 applies because no parameter documentation is needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('Return') and object ('metadata for a public evidence reference'), distinguishing it at a basic level from sibling tools that assemble, explain, status, or feedback. However, it does not explicitly explain how 'evidence' differs from those siblings beyond the phrase 'public evidence reference.'

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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 context_status or context_explain, and no when/when-not conditions. The qualifier 'public' implies a scope, but no alternatives are named, leaving the agent to infer usage.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

context_explainB

Read-only

Explain public context package assembly metadata.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.2/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description is consistent with that. It adds minimal context with the word 'public,' implying broader accessibility, but does not disclose output format, limitations, or any other behavioral details beyond the safe-read profile.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with no filler. It is concise, though it could be slightly more informative without becoming verbose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema and no parameter information, the description alone does not explain what an 'explanation' contains, how it differs from status or evidence siblings, or what the agent should expect as a return value. The tool is simple, but the description is still too thin for confident invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are zero parameters and schema description coverage is effectively 100%, so the description does not need to add parameter-level detail. The tool's behavior is not parameter-dependent.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb ('Explain') and a specific resource ('public context package assembly metadata'), so the core action is identifiable. It does not explicitly differentiate from siblings like context_status or context_evidence, but the 'explain' + 'metadata' phrasing provides enough initial distinction.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to use this tool versus siblings such as context_status or context_feedback. The description does not state typical triggers, exclusions, or alternatives, leaving the agent to infer the intended use.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

context_feedbackC

Submit metadata-only feedback about context package usefulness.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

C2.4/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description mentions 'metadata-only' which suggests no side effects on the context package itself, but this is minimal. The annotations show readOnlyHint=false and destructiveHint=false, which is ambiguous. The description doesn't elaborate on what 'feedback' entails, how it's stored, or any effects on the context system. It relies on the annotations but adds little beyond them.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence, front-loaded with the key constraint ('metadata-only'). It is minimal but not under-specified to the point of tautology, and every word adds meaning.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has no output schema and no parameter schema, so the description must carry the full burden of explaining what the tool does and how to use it. It only states the purpose in a vague way and lacks details on the feedback structure, expected behavior, or error conditions. This is insufficient for an agent to know how to invoke it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema is empty with additionalProperties: true. Schema coverage is 100% because there are no parameters to document. The description mentions 'metadata-only feedback' but does not specify what metadata fields are expected or how they should be provided. Since there are zero parameters, the baseline is 4, but the description fails to clarify the free-form nature, so a 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description says 'metadata-only feedback about context package usefulness', which gives a general idea but lacks a specific verb and resource. It doesn't distinguish from siblings like context_status or context_evidence. The verb 'submit' is implied but not stated, making the purpose somewhat vague.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to use this tool versus alternatives. The sibling tools (context_assemble, context_explain, context_evidence, context_status) suggest related actions, but the description doesn't explain why an agent would choose this over them. No exclusions or prerequisites are mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

context_statusA

Read-only

Check ContextECF MCP facade readiness.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.7/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The annotations already declare readOnlyHint=true and destructiveHint=false, and the description's 'Check' is consistent with a read-only operation. The description adds the scope 'ContextECF MCP facade readiness' but does not disclose what readiness means, whether it performs network calls, or what the returned status indicators are. For a simple status check, this is acceptable but not rich.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with no filler or repetition. It states the action and the target clearly, making it easy for an agent to parse quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given that the tool has no parameters and no output schema, the description provides enough information for a basic status/readiness call. The main gap is the lack of detail about what a successful response looks like or what 'readiness' specifically measures, but the simplicity of the tool reduces the need for extensive context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, and the schema confirms an empty object with 100% coverage, so no parameter documentation is needed. The description does not need to explain parameter semantics because there are none to explain.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a clear verb ('Check') and identifies the resource ('ContextECF MCP facade readiness'), which aligns with the tool name and the annotated title 'Check connector status'. It is reasonably specific, though 'readiness' is slightly vague and does not explicitly distinguish from siblings by name, but none of the sibling names suggest a status/readiness function.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use the tool: when an agent wants to verify whether the ContextECF MCP facade is ready or its status. However, it does not provide explicit guidance about prerequisites, when not to use it, or how it relates to sibling tools like context_assemble or context_evidence.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

5 tool updatesv0.1.0Sep 18, 2026
- First observedcontext_assemble
- First observedcontext_evidence
- First observedcontext_explain
- First observedcontext_feedback
- First observedcontext_status

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

B3.3/5.0

Scored 2026-09-18 18:45 across 5 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: assembling packages, explaining package metadata, fetching evidence metadata, checking server readiness, and submitting feedback. There is no meaningful overlap or ambiguity between the five tools.

Naming Consistency3/5

All tools share the consistent 'context_' prefix and use snake_case, which is helpful. However, the second part mixes verbs (assemble, explain) with nouns (evidence, status, feedback), so the naming convention is not uniformly verb-driven.

Tool Count5/5

Five tools is a well-scoped size for this server's purpose. Each tool contributes a distinct capability, and the count feels neither bloated nor thin.

Completeness4/5

The core workflow of assembling, explaining, and referencing context package metadata is covered, along with status and feedback. A minor gap is the lack of a listing or search tool for discovering available public packages or evidence references, but this does not break the main use case.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

LobuOAuth
io.github.lobu-ai
Shared, permission-aware company context for AI agents, with provenance, approvals and audit.
Knowledge & Memory Security
1223
XGuard — Agent Execution Gateway B
io.github.moelayyan90
Scoped agent execution. Server-side credentials, policy, budgets and verifiable receipts.
Finance Security
81
FreshContext A
io.github.PrinceGabriel-lgtm
Context integrity for AI agents: evaluate freshness, confidence, provenance, and decision readiness.
Web Scraping Search Agent Orchestration
22212
FullmaktOAuth
ai.fullmakt
Credential broker for AI agents: scoped, revocable API access with policy enforcement and audit.
Security Autonomous Agents Agent Orchestration
1

Related MCP Servers

repolens
cognis-digital
A
license
A
quality
C
maintenance
Enables LLM agents to acquire token-budgeted, deterministic context packs from repositories, with hash-chained provenance for auditability.
Updated 2 months ago (2026-07-26 07:15 UTC)
2
MIT
Lemma Oracle MCP Serverofficial
AI & Machine Learning Security Autonomous Agents
lemmaoracle
A
license
Not graded
quality
A
maintenance
Enables AI agents to query cryptographically verified facts with zero-knowledge proofs, selective disclosure, and tamper-evident provenance.
Updated a day ago (2026-09-22 17:10 UTC)
336 npm
1
Apache 2.0
KB Platform MCP Server
RAG Systems Search Security
Syntax753
A
license
Not graded
quality
B
maintenance
Enables governed, audit-traced AI access to a curated knowledge base through the Model Context Protocol, with OAuth 2.1 authentication and policy enforcement for secure, compliant queries.
Updated 2 months ago (2026-08-01 05:31 UTC)
Apache 2.0
orcha-mcp
RAG Systems Knowledge & Memory Search
westonhancock
F
license
Not graded
quality
B
maintenance
Provides a unified context layer for AI agents, enabling ranked search, file management, context bundles, database queries, and connected source access through MCP, all scoped to organizational permissions with citations.
Updated a month ago (2026-08-10 05:05 UTC)
-

ContextECF MCP

Tools

MCP Request Shape

Use ContextECF With Claude

Configuration

Docker

Synthetic Live Demo

How Context Assembly Works

Boundary

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Lemma Oracle MCP Serverofficial