ContextForge MCP

cf_tools

Destructive

Search and run 55 extra ContextForge capabilities like git sync, spaces, projects, and task editing. Use it to find any capability missing from your tool list.

Instructions

Discover and run 55 additional ContextForge capabilities that are not in your tool list: git sync and history, spaces, projects, skills, routines, snapshots, import/export, task editing, and collaboration. If you cannot find a ContextForge capability in your tool list, search for it HERE before concluding it does not exist. Two modes: pass query with a plain-language description to search (returns full, ready-to-call schemas of the best matches), or pass name plus args to run one.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "cf_tools"
  }
}

Input Schema

Name	Required	Description
`args`	No	Arguments for the tool named in `name`.
`name`	No	Exact tool name to execute, as returned by a previous `query` call.
`query`	No	Plain-language description of the capability you need, e.g. 'sync git commits' or 'forget an outdated memory'. Returns full schemas of the best matches.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.13.3Nov 11, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=false and destructiveHint=true, and the description is consistent with that by describing an execution path. It adds real behavioral context the annotations do not: search returns full ready-to-call schemas of the best matches, and the fallback-before-concluding behavior. It stops short of warning that capabilities executed via name+args may mutate or delete data, which would have been valuable given destructiveHint=true.

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?

Three sentences, front-loaded with what the tool is, then the routing rule, then the mode mechanics. The capability enumeration doubles as search keywords rather than filler, and no sentence is redundant with another.

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?

There is no output schema, and the description covers the search return (full schemas of best matches) but not what execution mode returns or how an unknown name is handled. For a meta-tool that proxies 55 capabilities, that is a modest but real gap; the core decision path is otherwise fully specified.

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?

Schema coverage is 100%, so the baseline is 3, but the description adds the cross-parameter contract the schema only implies: query is a standalone search mode returning schemas, while name and args form the execution mode, and name must be an exact tool name returned by a prior query. That mode pairing is genuine meaning beyond the field-level descriptions.

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?

Uses a specific verb pair (discover/run) on a precisely scoped resource: 55 ContextForge capabilities not present in the current tool list, with concrete categories enumerated (git sync, spaces, projects, skills, routines, snapshots, import/export, task editing, collaboration). It is unmistakably a meta/gateway tool and cannot be confused with the flat siblings like memory_query or tasks_list.

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

Usage Guidelines5/5

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

States an explicit routing rule: if a ContextForge capability is missing from the tool list, search HERE before concluding it does not exist. It then splits the two invocation modes and gives the condition for each (query alone to search, name plus args to execute), leaving no ambiguity about which branch to take.

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

Deploy Server