Heuresis MCP server

Read from the package source without running it. The installed server may list more.

• add_conceptwrite action

  Create a new concept (Node). If parentId is given, the concept becomes a CHILD of that concept and a partition edge is auto-created. If parentId is omitted, the concept attaches to the project root.

• add_kref

  Convenience: create a k-ref (knowledge reference) edge from fromId → toId. Equivalent to link_concepts with kind=k-ref.

• add_to_idea

  Add a single concept to an existing Idea (idempotent).

• archive_concept

  Archive a concept (status=archived). Reversible via unarchive_concept.

• bulk_add_conceptswrite action

  Create many concepts in a single atomic transaction. `items` is an array; each item carries label / description? / parentId? / projectId? / tags?. project_id is resolved per-item (explicit > inherited from parent > workspace solo project). Returns the created ids in input order.

• create_ideawrite action

  Create a new Idea (a named grouping of concepts) with an optional color and optional starting node membership.

• create_projectwrite action

  Create a new Project (problem-with-direction) with a name and brief. Optional `direction`.

• delete_ideawrite action

  Delete an Idea. Membership rows cascade via FK; the underlying concepts are untouched.

• delete_projectwrite action

  Delete a project. Project_nodes / problem_frames / closed_worlds / lab_matrix_cells cascade via FK. Concepts that belonged to ONLY this project are orphaned (project_id → NULL) — they are NOT auto-deleted.

• expand_concept

  Recursive Branch — expand a concept by `breadth` children at each of `depth` levels (depth*breadth ≤ 60). Commits each level immediately so the webapp shows partial results as the run progresses. Optionally takes an `angle` hint that biases the underlying EXPLORE operator. Best when the anchor has few or no children yet; on a dense subtree consider `run_operator(family="explore")` so the operator

• find_concepts

  Find concepts by label/substring match. Returns up to k hits, each with id, label, status.

• get_concept

  One concept by id, optionally with its ancestry (parent chain), direct children, and idea memberships.

• get_project_graph

  Every node + edge inside one project. Returns a graph the agent can reason over end-to-end. Use for project-wide questions.

• get_subtree

  A node and its descendants up to a given depth. Use when the user asks "tell me about everything under X".

• get_workspace_summary

  Counts of nodes / edges / projects / ideas + a one-line overview of each project and idea. Always start here when you don't know what's in the workspace.

• link_conceptswrite action

  Create an edge between two concepts. kind is one of: 'k-ref' (knowledge reference), 'derived-from' (provenance link), 'semantic-adjacency' (sibling kinship). Partition (parent/child) edges are managed via add_concept / set_parent.

• list_concepts

  List concepts in the workspace or one project. Returns id / label / status / parentId / tags up to `limit` entries (default 500). Use BEFORE making changes to learn what already exists.

• list_edges

  List every edge in the workspace (or restricted to a project). Filter by kind: partition / k-ref / semantic-adjacency / derived-from / imported-from.

• list_projects

  Every project in the workspace with brief, direction, lifecycle, and node count. Use this to figure out which project the user is asking about.

• list_recent_decisions

  Nodes the user has explicitly resolved (validated, starred, or archived) recently. Use to surface "what did we conclude last week" without a full scan.

• recolor_idea

  Change an Idea's color (any CSS color string).

• remove_conceptwrite action

  Hard-delete a concept and its descendants (walks the parent_id subtree). Edges and project/idea memberships cascade via FK. Refuses to delete a project root node.

• rename_idea

  Rename an Idea.

• run_operatorwrite action

  Run an ASIT / TRIZ / Contradiction / Free / Combine / Explore operator against one concept (the anchor). Returns CANDIDATE concepts WITHOUT committing them — call `bulk_add_concepts` (or `run_operator_and_commit`) to persist. Use this when you want the agent to vet the candidates before writing. The anchor must already live in a project; the operator pulls in ancestry + validated knowledge in the

• run_operator_and_commitwrite action

  Same as `run_operator`, but immediately writes every top-level candidate as a child of the anchor with a partition edge and a provenance row stamped origin='mcp'. Use when the agent is confident the candidates should land directly on the canvas (e.g. inside an autonomous expand loop). Children-of-children proposed in `partitions[].children` are NOT auto-committed — request them via a separate run.

• search_concepts

  Substring search across concept labels, descriptions, partition attributes, rationale, and tags. Use this when the user mentions a concept by name and you don't have its id. (Semantic search is a Phase 19.5 enhancement.)

• set_idea_members

  Replace an Idea's full membership with `nodeIds`. Reconciles the junction table: inserts missing pairs, deletes pairs no longer in the set. Returns added / removed counts.

• set_parent

  Re-parent an existing concept: nodeId's parent becomes newParentId (or detached when null). Updates BOTH node.parent_id AND the partition edge so the canvas tree stays in sync.

• set_standing

  Set a concept's STANDING — how known / proven the idea is in the wider world. `standing` ∈ 'novel' | 'emerging' | 'established' | 'unknown'. `rationale` is a one-sentence justification (saved as `standing_rationale`). Use this when classifying / judging novelty.

• star_concept

  Toggle the starred flag on a concept (user-favorite marker).

• unarchive_concept

  Revive a previously-archived concept (status=open). Idempotent on already-open nodes.

• update_conceptwrite action

  Update an existing concept's label, description, tags, partitionAttribute, rationale, or status. Only the fields provided are changed.

• update_projectwrite action

  Update a project's name / brief / direction / lifecycle. Only fields provided are changed.

• validate_concept

  Mark a concept as validated (status=validated). Optionally also overwrite `rationale`. Idempotent on already-validated nodes.

• Code scan26 source files scanned25/25
• –Live reliabilityno gateway calls yet and no remote to proben/a
• –Tool poisoningtools not inspected (local package is not executed); not countedn/a
• Auth qualitylocal package, no credentials required12/15
• Maintenancelast push 113 days ago8/15
• Maintainer identityregistry namespace matches repository owner; GitHub account older than a year8/10

Safety score

82/100

higher than 63% of 48,255 servers

Tools

34

the typical server has 7

Tools that change things

35%

typical: 0%. Fewer write tools means less an agent can break

Downloads a week

33

more than 22% of 12,191 servers with a package

Heuresis: common questions

Is Heuresis MCP server safe?

Mostly: it is graded B (82/100). Read the Heuresis safety report

How do I install Heuresis?

It runs on your machine. Copy the Claude Code, Cursor, VS Code or Claude Desktop config from the install section.

Does Heuresis need an API key?

Not as far as the registry entry and our scan can tell: no credentials are declared or required.

Is Heuresis maintained?

The last commit was 151 days ago (2026-06-06). The latest release is v1.0.0-rc.9.

How does Heuresis compare with other MCP servers?

safety score 82/100 (higher than 63% of 48,255 servers); tools 34 (the typical server has 7); tools that change things 35% (typical: 0%. Fewer write tools means less an agent can break). Full comparison.