# Enhanciar — company brain

> Ask your company's Slack, Gmail, Drive, Notion, Jira and code from any MCP client, with sources.

- name: in.enhanciar/enhanciar
- version: 1.0.4
- connection class: R1 (autonomous)
- trust: 83/100 flags: no-repository
- quality: 81/100 (good)
- owner: not claimed
- descriptor: https://api.protogrid.dev/v1/servers/in.enhanciar%2Fenhanciar
- tools: https://api.protogrid.dev/v1/servers/in.enhanciar%2Fenhanciar/tools

**An agent can connect on its own if it already holds `ENHANCIAR_TOKEN`.** Remote endpoint behind a static API key or header. The registry never sees the value; the agent fills the placeholder.

## Connection (mcpServers)

```json
{
  "mcpServers": {
    "enhanciar": {
      "type": "http",
      "url": "https://enhanciar.in/enhanciar/mcp/",
      "headers": {
        "Authorization": "Bearer ${ENHANCIAR_TOKEN}"
      }
    }
  }
}
```

Placeholders to fill: `${ENHANCIAR_TOKEN}`.

## Trust

- hygiene: 80
- liveness: 100
- freshness: 100
- provenance: 55
- drivers: +dns-namespace +website +reachable +uptime-100% +updated-4d-ago -no-repository
- Derived from observable signals (official registry feed and our own credential-free probes); no code audit performed.

## Quality 81/100 (good)

### protocol: n/a (weight 25)

- n/a `protocol.modern`, `protocol.stateless`, `protocol.transport`, `protocol.list_ttl`: no remote answered a protocol handshake (not probed yet, unreachable, or local-only)

### authorization: n/a (weight 15)

- n/a `auth.prm`, `auth.as_metadata`, `auth.cimd`: no remote uses OAuth
- n/a `auth.secret_in_url`: no templated URL

### tool hygiene: 71 (weight 30)

- pass `tools.descriptions`: every tool has a description
- pass `tools.description_length`: descriptions are concise
- pass `tools.schemas`: every tool has an object input schema
- fail `tools.annotations`: no tool declares readOnlyHint or destructiveHint, so clients cannot tell safe calls from risky ones
- fail `tools.directory_hints`: no tool declares all four of readOnlyHint, destructiveHint, idempotentHint and openWorldHint; missing: impact (readOnlyHint, destructiveHint, idempotentHint, openWorldHint); get_graph (readOnlyHint, destructiveHint, idempotentHint, openWorldHint); list_pages (readOnlyHint, destructiveHint, idempotentHint, openWorldHint); …
- pass `tools.token_cost`: about 2,028 tokens to load every tool
- pass `tools.api_dump`: tools are not a one-to-one API dump

### stability: 100 (weight 15)

- pass `stability.changes`: 1 tool changes in 30 days
- pass `stability.rug_pull`: no tool changed its meaning under the same name

### dependencies: n/a (weight 15)

- n/a `deps.known_vulns`, `deps.mcp_sdk_version`, `deps.resolvable`: no npm or PyPI package

- tools: 12, about 2,028 tokens to load them all
- tool set hash: 2234b098e44d562e42b9ee8e25a2bcce
- tools last changed: 2026-09-30T15:54:42.963Z
- badge: [![protogrid quality](https://protogrid.dev/badge/in.enhanciar/enhanciar.svg)](https://protogrid.dev/servers/in.enhanciar/enhanciar)
- Checks run on what our credential-free, read-only probes observe; tools are never called and no code audit is performed.

### Tool changes

- 2026-09-30 `get_page` changed (inputSchema)

Full history: https://api.protogrid.dev/v1/servers/in.enhanciar%2Fenhanciar/changes

## Remotes

- https://enhanciar.in/enhanciar/mcp/ (streamable-http, auth api_key ${ENHANCIAR_TOKEN}, reachable true, uptime30d 1)

## Packages

_none_

## Tools (12)

- `get_graph`: Return the community/knowledge graph manifest for visualisation.

Useful when the calling agent wants the high-level structure of the
key's workspace (clusters, hub nodes, cross-references) rather than
the contents of any one page. Returns ``{nodes, edges, communities,
stats}`` — exact shape mirrors the ``/api/wiki/graph`` REST endpoint.

- `get_page`: Fetch a single wiki page from the key's workspace.

Args:
    category: One of ``entities | concepts | people | decisions |
        sources | flows | infrastructure | tickets``.
    name: Page slug (without ``.md`` extension), as returned by
        ``list_pages`` / ``search_wiki``.

Returns ``{category, name, content}`` — ``content`` is the full
markdown body including YAML frontmatter. Returns ``{error: "..."}``
if the page doesn't exist.

- `get_process_map`: Return the "living map of how the company works" for the key's workspace.

A graph of process nodes (compiled skills), the external systems
they touch (GitHub, Slack, Jira, …), the wiki docs they were
derived from, and team groups — with derived_from / uses /
references edges. Use this when the agent wants the high-level
operational structure rather than one skill's steps.

- `get_skill`: Fetch one compiled skill by name (slug from ``list_skills``).

Returns ``{name, markdown, meta}`` — ``markdown`` is the full
agent-executable SKILL.md content (frontmatter + steps), ``meta``
is the parsed frontmatter. Includes an ``error`` key when the
skill doesn't exist (with the available names).

- `impact`: Compute the blast radius of changing ``target`` in the key's workspace.

Use this before editing code to see what a change ripples into:
direct callers/callees, every affected file, the affected tests, the
transitive dependency set, and example dependency paths with per-path
facts (hops, dependents at the endpoint, whether it lands in a test).

There is deliberately no risk score. There was one — thresholds on the
transitive count — and it was a verdict the caller could not check or
argue with. The counts it was computed from are all here; judge from
those.

Args:
    target: A graph node id, wiki page name, file path
        (``micrograd/engine.py``), or a function fqn (``engine.py::func``).
    depth: How many hops to traverse the call graph (default 2).

Returns the impact dict — ``{target, label, found, direct_callers,
direct_callees, affected_files, affected_tests, transitive_nodes,
transitive_count, paths, path_facts}``.

- `list_pages`: List every wiki page the caller can see in the key's workspace.

Returns a list of ``{category, name, title}`` records — feed each
one to ``get_page`` to fetch the full markdown body. Use this first
when you want a directory view; for a specific question prefer
``query`` which handles retrieval for you.

- `list_proposed_actions`: List the key's workspace's proposed actions (the approval queue).

Read-only. Optionally filter by ``status`` (proposed / approved /
executing / done / failed / dismissed). Returns ``{id, action_type,
status, source, title, source_doc_id, external_id}`` per proposal.

NOTE: MCP can read and PROPOSE actions but deliberately cannot approve
or execute them — a human approves every action in the app UI.

- `list_repos`: List the repos ingested into the key's workspace.

Returns ``{full_name, branch, last_ingested_at}`` records. Use this when
the agent needs to know what context is available before asking a
question.

Reads what ingest actually recorded for this namespace: ``repos.json``
(the repo→clone map every other read path resolves through) plus the
per-repo ``_state`` files that carry the branch and the last run's
timestamp.

It used to read a Firestore subcollection ``users/{uid}/repos``, which
was wrong twice over. It was keyed by the person rather than the
workspace — the bug this module was fixed for — and nothing in the
codebase has ever written to that path, so the tool returned an empty
list to everyone, forever. Hence ``branch`` rather than the old
``default_branch``: the state file records the branch that was actually
ingested, and no caller can be depending on a key that never had a row
under it.

- `list_skills`: List the compiled skills (recurring procedures) in the key's workspace.

Skills are agent-executable SKILL.md pages mined from that workspace's
wiki by the skills compiler. Returns ``{name, title, description,
confidence, last_compiled, sources}`` records — feed a ``name`` to
``get_skill`` for the full markdown. Empty list = nothing compiled
yet (the user can run a compile from Enhanciar's UI or API).

- `propose_action`: Propose a new action for human approval (does NOT execute it).

``action_type`` is a registered executor id (e.g. ``jira.create_issue``,
``linear.create_issue``, ``github.create_issue``). The proposal lands in
the key's workspace's approval queue where a person picks the target and
approves it — approve/execute are intentionally NOT exposed over MCP.
Returns the created ``{id, action_type, status}`` or an ``error``.

- `query`: Ask Enhanciar a natural-language question grounded in the key's workspace.

This is the high-level tool — use it for any "what does X do",
"why did we choose Y", "where is Z handled" question. It runs
the full retrieval + synthesis pipeline and returns the answer
plus citations.

Args:
    question: Natural-language question.
    model: Optional model id override (``gemini-2.5-flash``,
        ``gpt-4o``, ``claude-sonnet-4-5``, etc.). If omitted the
        saved default is used — the workspace's in a team workspace,
        the caller's own in a personal one.

Returns ``{answer, sources, model}`` — ``sources`` is a list of
``{category, name, url}`` citations the LLM grounded its answer
in. Surface them to the human so they can verify. When the workspace
has nothing ingested at all you get ``{answer, empty_brain: true}``
and no sources: that is a statement about the workspace, not a failed
search, so rephrasing the question will not change it.

- `search_wiki`: Substring search across the wiki pages in the key's workspace.

Cheap and deterministic — no embedding required. Returns up to
``limit`` (default 20, max 50) ``{category, name, title, snippet}``
hits. The ``snippet`` is a short window around the first match,
safe to surface in chat as a citation preview.

For semantic / natural-language questions prefer ``query``.