Enhanciar is an AI company brain for every team. It reads your Slack, Gmail, Google Drive, Notion, Confluence, Jira, Linear, Zendesk, GitHub code and databases, writes a wiki from them, and answers questions from any MCP client with a link to the source. Tools: query (cited answers), search_wiki, get_page, list_pages, get_graph, get_process_map, impact (what a code change touches), list_repos, list_skills, get_skill, propose_action and list_proposed_actions (tickets, Slack messages, Gmail drafts, Notion pages and calendar holds that a person approves first). Hosted service, bring your own AI key. Plans: Solo $24 a month, Team $100 a month for up to 10 people. Create an API key in Settings at https://enhanciar.in.
Scored across 12 tools
Each tool has a clearly distinct purpose, and the descriptions explicitly cross-reference alternatives (e.g., 'use get_page for text, impact for code'). Retrieval tools (query, search_wiki, get_page) are differentiated by intent and cost, and structural tools (get_graph, get_process_map, impact) target separate graph types.
All names follow a strict snake_case verb_noun pattern (get_, list_, search_, propose_) or a single noun (impact, query), which is consistent and predictable. No mixed casing or style deviations.
12 tools are well-scoped for a company brain covering wiki, code, skills, processes, graph, and actions. Each tool earns its place without redundancy.
The surface covers the full lifecycle of its domain: reading (get_page, list_pages), searching (search_wiki, query), structural analysis (get_graph, get_process_map, impact), code (list_repos), skills (list_skills, get_skill), and actions (propose_action, list_proposed_actions). Approval is intentionally human-only and documented, leaving no agent-facing gaps.
Return the workspace's knowledge graph: topics, links and clusters.
Use it to draw or reason about the overall shape of the brain (which
topics are hubs, how areas connect), not to read content: for page
text use get_page, for code dependencies use impact. It takes
no arguments and can be large. Returns {nodes, links, communities, stats}, the graph the app's Map shows, with pages you cannot open
left out, or {error} when no graph has been built for this
workspace yet. It costs no AI tokens.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden and meets it: it discloses that the tool takes no arguments, can be large, may return an {error} when no graph has been built, omits pages the caller cannot open, and costs no AI tokens. Size and failure-mode disclosure are exactly what an agent needs for a potentially heavy call.
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?
Front-loaded with the purpose, then scope, then alternatives, then return shape and cost. Every clause earns its place — the sibling pointers and the token-cost note each change agent behavior.
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?
Though an output schema exists (so return values need not be spelled out), the description still summarizes the shape and documents the empty-graph error case and the exclusion of unopenable pages. Combined with the no-args and cost notes, an agent has everything needed to call it correctly.
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 schema has zero parameters and 100% coverage, so the baseline is 4. The description reinforces this by stating it 'takes no arguments', which prevents an agent from hunting for a filter parameter.
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?
States a specific verb and resource: 'Return the workspace's knowledge graph: topics, links and clusters.' It further differentiates from siblings by naming get_page for page text and impact for code dependencies, so an agent can route correctly without opening any schema.
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?
Explicit when-to-use ('to draw or reason about the overall shape of the brain — which topics are hubs, how areas connect') and explicit when-not ('not to read content'), with the two alternative tools named for each excluded case. Nothing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the full text of one wiki page.
Use it after search_wiki or list_pages when you need the
whole page, or to open a page query cited. Pass category and
name from those results, or one path like
"concepts/billing-flow". Returns {category, name, content}, where
content is the page's Markdown including its YAML header (title,
sources, dates). A missing or hidden page returns {error} saying
what to pass instead; it costs no AI tokens.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | String. The page's ``name`` from ``list_pages`` or ``search_wiki``, without ".md", e.g. "billing-flow". Default ""; give this or ``path``. | |
| page | No | String. Same as ``name``; accepted for clients that send it. Default "". | |
| path | No | String. Category and name in one, e.g. "concepts/billing-flow"; use instead of ``category`` + ``name``. Default "". | |
| slug | No | String. Same as ``name``; accepted for clients that send it. Default "". | |
| title | No | String. Same as ``name`` (the page's name, not its display title); accepted for clients that send it. Default "". | |
| category | No | String. The page's folder, from a ``list_pages`` or ``search_wiki`` result, e.g. "concepts". One of: entities, concepts, people, decisions, sources, flows, infrastructure, tickets, chats, mail, docs, conversations, schemas, skills. Default "": found from ``name``. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses the return shape ({category, name, content}), that content is Markdown including the YAML header, and the error behavior for missing/hidden pages with a note that failures cost no tokens. It doesn't cover pagination or permissions, but for a read tool this is solid behavioral disclosure.
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?
Front-loads the core purpose in the first sentence, then covers usage, inputs, and return/error behavior in a few tight sentences with no filler. Slightly dense with inline literals, but every sentence earns its place.
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?
An output schema exists, so return values needn't be explained, yet the description still adds the error case and the Markdown-with-frontmatter nature of content. Combined with the sibling routing and alias handling, an agent has everything needed to call it correctly.
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 100%, so the schema already documents all six parameters and their aliases. The description adds only routing context ('Pass category and name from those results, or one path'), so baseline 3 is correct.
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?
States a specific verb and resource ('Read the full text of one wiki page') and immediately distinguishes itself from siblings by saying it is used after search_wiki or list_pages. An agent can tell exactly what it retrieves without opening the schema.
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?
Names the alternatives (search_wiki, list_pages, query) and the condition that selects this tool: when you 'need the whole page' or want to open a page that query cited. Explicit when-to-use routing, nothing left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Map how the company works: procedures, the tools they use, their docs.
Use it for the big picture ("which processes touch Jira?", "what do
we run through Slack?"); for the steps of one procedure use
get_skill, and for the topic graph use get_graph. It takes no
arguments and rebuilds the map from the compiled skills on each call.
Returns {nodes, edges}: nodes have {id, label, kind} with kind
process, system, doc or team, and edges have {from, to, rel} with
rel such as derived_from, uses or references. With no skills compiled
the lists are empty and a message says why.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden and does well: it declares zero arguments, discloses that the map is rebuilt from compiled skills on every call (a cost/freshness signal), and defines the empty-state behavior (empty lists plus a 'message' explaining why). It stops short of stating permission requirements or expected latency, so it is strong but not exhaustive.
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?
Front-loaded with the purpose, then routing, then behavior in a clean progression. The closing sentence detailing the return shape ({nodes, edges}, kind/rel enums) partially duplicates the output schema, so it is slightly longer than strictly necessary, but no sentence is wasted.
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?
For a zero-parameter, read-only map tool with an output schema, the description covers purpose, routing, argument count, rebuild semantics, and the empty-result case. Nothing an agent needs in order to call it correctly or interpret an empty response is missing.
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 tool takes zero parameters, which is the baseline-4 case; the description reinforces this with 'It takes no arguments.' Nothing further is needed on this dimension.
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?
States a specific verb and resource ('map how the company works: procedures, tools, docs') and immediately disambiguates against the two nearest siblings, get_skill and get_graph. An agent can tell exactly which tool answers 'big picture' questions without opening any schema.
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?
Gives explicit when-to-use framing with concrete example questions ('which processes touch Jira?', 'what do we run through Slack?') and routes users to get_skill for a single procedure's steps and get_graph for the topic graph. Both the use case and the alternatives are named, not implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the full steps of one skill (a recurring team procedure).
Use it after list_skills when you are about to carry out or
explain a procedure the team repeats. Returns {name, markdown, meta}: markdown is the whole SKILL.md (header plus numbered
steps) and meta is its parsed header. An unknown name returns
{error} listing the names that do exist.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | The skill's ``name`` from ``list_skills``, e.g. "cut-a-release". Case, spaces and a trailing ".md" are tidied for you. Required. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden, and it does so well: it discloses the return shape ({name, markdown, meta}), explains what markdown and meta contain, and describes the failure mode (unknown name returns {error} listing existing names). It does not cover permissions, size limits, or pagination, but for a read tool that is a minor gap.
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?
Three short sentences, front-loaded with the purpose and immediately followed by the usage trigger and return contract. No filler, no restatement of the name, and the error behavior is placed last where it belongs.
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 one required parameter, full schema coverage, an existing output schema, and no nested objects, the description covers exactly what is needed: what it returns, when to call it, and what happens on failure. Nothing an agent needs to invoke it correctly is missing.
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 100% and the schema already documents 'name' as required with format-tidying notes and an example, so the baseline is 3. The description only reinforces that the name comes from list_skills and that unknown names error — useful but not meaningfully additive over the schema.
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?
States a specific verb and resource ('Read the full steps of one skill') and defines scope by distinguishing it from the sibling list_skills, which only enumerates skills. An agent can tell it apart from list_skills, get_page, and get_process_map without opening any schema.
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?
Gives explicit sequencing and context: 'Use it after list_skills when you are about to carry out or explain a procedure the team repeats.' It names the prerequisite tool and the triggering situation. It stops short of stating when NOT to use it (e.g. browsing vs. executing), so it is not a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show what else breaks or needs retesting if you change a file or function.
Use it before editing ingested code, or to review a change: it walks
the code graph built at ingest. For "why is it built this way" ask
query; to see which repos are ingested use list_repos. Returns
{target, label, found, direct_callers, direct_callees, affected_files, affected_tests, transitive_nodes, transitive_count, paths, path_facts}; path_facts gives each sample path's hops,
dependents and whether it ends in a test. found: false means the
target is not in the graph, so check the spelling or ingest the repo.
| Name | Required | Description | Default |
|---|---|---|---|
| depth | No | How many call hops to follow out from the target, e.g. 3. Default 2; values below 1 count as 1. Higher finds more but returns a bigger result. | |
| target | Yes | What you plan to change: a file path as ingested, e.g. "micrograd/engine.py"; a function as "file::name", e.g. "engine.py::backward"; or a graph node id or wiki page name. Required. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so the description must carry the load—it does: explains it walks the ingest-time code graph, defines the 'found: false' failure mode with remediation, and describes output shape including path_facts semantics.
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?
Front-loads the purpose, then usage, then return shape and failure mode; a little verbose in enumerating return keys, but each section serves routing or interpretation.
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?
For an unannotated analysis tool with an output schema, the description covers purpose, usage, sibling routing, return semantics, and the not-found case—everything needed to call it correctly.
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 100%, so baseline 3 applies; the description doesn't elaborate param formats beyond what the schema already documents (target and depth are fully described there).
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?
States a specific verb (show what breaks/needs retesting) and resource (file or function), and explicitly differentiates from siblings by naming 'query' for rationale and 'list_repos' for repo listing.
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?
Gives explicit when-to-use ('before editing ingested code, or to review a change') and routes to alternatives for adjacent needs ('why is it built this way' → query; which repos → list_repos).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List every wiki page you can see in this workspace, unfiltered.
Use it for a table of contents or to see which categories exist. It
takes no arguments and can return hundreds of rows on a big workspace,
so to find pages on a topic use search_wiki, and to answer a
question use query. Returns a list of {category, name, title},
e.g. {"category": "concepts", "name": "billing-flow", "title": "Billing Flow"}; pass category and name to get_page.
Pages a document's sharing rules hide from you are left out.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and does well: it discloses that the tool takes no arguments, that result size can reach hundreds of rows, and that pages hidden by a document's sharing rules are omitted. It does not explicitly characterize the operation as read-only or state whether there is pagination/truncation at that scale, which is the main remaining gap.
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?
Scope is front-loaded in the first sentence, alternatives follow, and the return shape plus the hand-off to get_page close it out. The inline example of {category, name, title} earns its space because it shows exactly which fields feed get_page.
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?
Even though an output schema exists and the description need not explain return values, it still supplies the shape and field semantics needed to chain into get_page. Combined with the scale warning, permission filtering note, and sibling routing, an agent has everything needed to call it correctly.
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 schema has zero parameters and the description confirms 'It takes no arguments,' so there is no ambiguity to resolve. Baseline for a 0-param tool is 4, and nothing here misleads about inputs.
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?
States a specific verb and resource ('List every wiki page') plus an explicit scope qualifier ('in this workspace, unfiltered'), which immediately separates it from filtered search tools. An agent can distinguish it from search_wiki and query without opening any schema.
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?
Names concrete use cases (table of contents, discovering categories) and explicitly routes the agent elsewhere: search_wiki for topic lookup and query for answering questions. It also warns that the tool returns hundreds of rows on large workspaces, giving the agent a reason to pick the alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the workspace's approval queue: actions proposed for a person to approve.
Use it to check what is already waiting before calling
propose_action (so you do not file a duplicate), or to see whether
something you proposed was approved and done. Read-only: over MCP you
can read and propose actions but never approve or run them; a person
does that in the Enhanciar app. Returns [{id, action_type, status, source, title, source_doc_id, external_id}], newest first;
external_id is the created ticket, message or draft once done.
If actions are not switched on for your account you get one
{error} row.
| Name | Required | Description | Default |
|---|---|---|---|
| status | No | Only return proposals in this state: "proposed" (waiting for a person), "approved", "executing", "done", "failed" or "dismissed", e.g. "proposed". Default "": every state. Any other value matches nothing. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and discharges it: it declares read-only semantics, states the hard MCP boundary (read and propose only — never approve or run; a human does that in the app), specifies ordering (newest first), and discloses the failure mode (a single {error} row when actions are disabled). That is unusually complete for a mutation-adjacent tool.
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?
Front-loaded with the one-line purpose, then scoped usage, then behavior, then return shape — a sensible ordering. Slightly denser than needed (the inline return-field list and error-row caveat lengthen it), but every sentence carries information an agent would otherwise have to infer.
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?
Covers the gaps an agent would hit: the queue is workspace-scoped, ordering is newest-first, external_id's meaning is explained, and the disabled-account path is flagged. With one optional parameter and an output schema present, nothing needed for correct invocation is missing.
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 100% and the status parameter is fully documented with all six values plus the empty-string default, so the schema does the heavy lifting. The description conveys the filtering intent ('what is already waiting' implies status=proposed) but adds no syntax or semantics beyond the schema. Baseline 3 applies.
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?
States a specific verb and resource — 'List the workspace's approval queue: actions proposed for a person to approve' — and immediately frames the queue as distinct from the sibling propose_action (the filing side). An agent can distinguish it from propose_action, list_pages, and list_skills without opening any schema.
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?
Gives explicit when-to-use guidance with a named counterpart: check the queue before calling propose_action to avoid filing duplicates, or verify a prior proposal was approved and done. The alternative (propose_action) and the condition selecting each are stated outright.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the code repos ingested into this workspace.
Call it first when a question or an impact target depends on
which code Enhanciar has read, or to check how fresh it is. It takes
no arguments and covers code only; connected tools like Slack or
Notion show up as wiki pages, so use list_pages or query for
those. Returns [{full_name, branch, last_ingested_at}], e.g.
{"full_name": "acme/api", "branch": "main", "last_ingested_at": "2026-10-01T09:30:00"} (null if unknown); an empty list means no
repo is ingested.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the load and does so well: it states the tool takes no arguments, that it covers code only, the exact return shape, that last_ingested_at can be null, and that an empty list means nothing is ingested. It omits auth/permission requirements and any rate or pagination behavior, which is the only remaining gap for a read-only listing tool.
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?
Front-loaded with the purpose in sentence one, then usage and scope, then return shape. Every sentence earns its place, though the verbose JSON example duplicates what the output schema already declares, adding length that could be trimmed.
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 a zero-argument tool with an output schema, the description supplies the missing operational context: when to call it, what it excludes, and how to interpret null and empty results. Nothing an agent needs in order to call it correctly is absent.
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?
Zero parameters, so the baseline is 4; the description reinforces this with 'It takes no arguments,' which removes any ambiguity about passing filters. No further parameter semantics are possible or needed.
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?
States a specific verb and resource ('List the code repos ingested into this workspace') and immediately bounds the scope to code, explicitly separating it from connected tools that surface as wiki pages. An agent can distinguish it from list_pages, query, and search_wiki without opening any schema.
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?
Gives an explicit trigger ('call it first when a question or an impact target depends on which code Enhanciar has read') plus a secondary use case (checking freshness), and names the alternatives to use instead for non-code content. This is when-to-use and when-not-to-use in one place.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the team's recurring procedures ("skills") Enhanciar wrote up.
A skill is a step-by-step how-to (cut a release, onboard a customer)
compiled from the wiki, written so an agent can follow it. Use this
when someone asks "how do we usually do X", then read one with
get_skill; for a one-off fact use query. It takes no
arguments. Returns [{name, title, description, confidence, last_compiled, sources}]; an empty list means none are compiled
yet (a person can run a compile in the Enhanciar app).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does well: it declares the tool takes no arguments, describes the return fields, and explains that an empty list means nothing is compiled yet, with the remediation path (a person runs a compile in the app). It never explicitly frames the call as read-only/side-effect-free, which is the only remaining gap.
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?
Front-loaded with purpose, then the definition, then usage routing — a sensible order with no filler. Slight overlap remains in enumerating return fields even though an output schema already documents them.
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?
For a zero-argument list tool with an output schema present, everything an agent needs is covered: purpose, trigger, follow-up tool, alternative tool, and the meaning of an empty result with its remedy.
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 tool takes zero parameters and the description confirms this explicitly ("It takes no arguments"), matching the empty schema. Baseline for a no-param tool applies; no additional parameter meaning is needed.
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?
States a specific verb and resource ("List the team's recurring procedures") and defines what a skill is — a step-by-step how-to compiled from the wiki. It also implicitly distinguishes itself from get_skill (single read) and query (one-off fact), so an agent can identify it without opening the schema.
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?
Gives an explicit trigger phrase ("how do we usually do X"), names the follow-up tool (get_skill), and names the alternative for a different need (query for a one-off fact). Both the when-to-use and the when-to-use-something-else conditions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
File a ticket, message, event or draft for a person to approve. Nothing runs yet.
Use it when the user asks you to create a Jira, Linear or GitHub
issue, post to Slack, book a calendar hold, draft an email, add a
Notion page or a Zendesk note. The proposal goes to the workspace's
approval queue, where a person picks the target (project, channel,
recipient), edits it if needed and approves; only then does it run.
Gmail actions only ever save a draft. Over MCP you cannot approve or
run anything; check the queue with list_proposed_actions first to
avoid duplicates. Returns {id, action_type, status: "proposed"},
{error: "duplicate", existing_id} if the same one is already
waiting, or {error} if actions are not switched on for your
account.
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | Short headline: the ticket or issue title, message summary or email subject, e.g. "Fix CSV export timeout for large accounts". Required. | |
| evidence | No | Optional note on why this is needed, such as a quote or a link to the Slack thread, e.g. "Customer asked in #support on 3 Oct". Shown to the person who approves. Default "". | |
| action_type | Yes | Which kind of action to file, e.g. "jira.create_issue". One of: gcal.create_event, github.create_issue, gmail.create_draft, jira.create_issue, linear.create_issue, notion.create_page, slack.ask_teammate, slack.post_message, wiki.reverify_page, zendesk.internal_note. gmail.create_draft only saves a draft and never sends; wiki.reverify_page asks a person whether a wiki page is still correct. Required; an unknown value returns the valid list. | |
| description | No | Optional body in Markdown: details, steps, links, e.g. "Export fails after 30s for accounts with 50k+ rows." Default "". |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so thoroughly: the proposal goes to a workspace approval queue where a person selects the target, edits, and approves before anything runs; Gmail actions only ever save a draft; approvals are impossible over MCP. It also discloses failure modes via the return shapes, including a duplicate early-exit error and an actions-disabled error.
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?
Front-loads the most important fact (nothing runs yet), then layers triggering examples, approval mechanics, dedupe guidance, and return contract in that order. Dense but every sentence carries distinct information; no 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?
For a 4-param proposal tool with no annotations, this covers the full picture: what it does, when to invoke it, the human-approval lifecycle, dedupe procedure, and both success and error return shapes. Even though an output schema exists, the explicit error cases (duplicate, disabled) fill the gaps an agent would otherwise guess at.
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 100%, so the schema already documents all four parameters including the accepted action_type values and the gmail.create_draft/wiki.reverify_page caveats. The description reinforces the Gmail draft behavior but adds no parameter syntax or format detail beyond the schema, so baseline 3 applies.
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?
States a specific verb and resource — "File a ticket, message, event or draft for a person to approve" — plus the critical qualifier "Nothing runs yet." An agent can immediately tell this is a propose-for-human-approval tool, distinct from execution-oriented siblings.
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?
Gives explicit triggering conditions (user asks to create a Jira/Linear/GitHub issue, post to Slack, book a calendar hold, draft email, add Notion page/Zendesk note) and names the alternative: check the queue via ``list_proposed_actions`` first to avoid duplicates. It also states the boundary clearly — over MCP you cannot approve or run anything.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Answer a plain-English question about the company, with sources.
Start here for "what does X do", "why did we choose Y", "where is Z
handled" or "what did we promise the customer": it picks the right
pages, writes an answer and cites them. It runs on the workspace's
own AI key, so it costs tokens and takes a few seconds; for exact
page text or a cheap lookup use search_wiki and get_page.
Returns {answer, sources, model}; sources lists the cited
pages as {category, name, url}, so show them to the person. If
the workspace has nothing ingested you get {answer, empty_brain: true}: rephrasing will not help. {error} means no AI key is
saved for the chosen provider.
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | Optional AI model id to answer with, e.g. "gemini-2.5-flash", "gpt-4o" or "claude-sonnet-4-5"; the provider's key must be saved in Enhanciar. Default null: the saved default model (the workspace's in a team workspace, yours in a personal one). | |
| question | Yes | The question in plain English, one topic per call, e.g. "Why did we move billing off Stripe?" or "Who owns the onboarding emails?". Required. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden and does so: it discloses that it runs on the workspace's AI key, costs tokens, takes a few seconds, and what each response shape means ({answer, sources, model}, empty_brain, {error} with the cause 'no AI key saved'). It also notes that rephrasing won't fix an empty brain — a genuinely useful behavioral warning.
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?
Front-loads purpose, then routing to siblings, then return shapes and failure modes — a sensible priority order with no filler. Despite covering a lot, every sentence carries distinct 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?
For a tool with no annotations, the description fully covers cost, latency, auth/key prerequisites, response shapes, and empty/error states; output schema existence means return values needn't be explained, yet the summary is brief and useful. Nothing needed to call it correctly is missing.
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 100%, so the schema already documents both question and model in detail, including the default-model semantics and the key requirement. The description reinforces context (AI key, one topic per call) but adds no new syntax or format detail beyond the schema, so the baseline 3 applies.
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?
States a specific verb and resource — 'Answer a plain-English question about the company, with sources' — and immediately distinguishes itself from siblings by naming search_wiki and get_page as the tools for exact page text or cheap lookups. An agent can select this over the alternatives without opening any schema.
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?
Gives explicit trigger phrases ('what does X do', 'why did we choose Y', 'where is Z handled'), says to start here for them, and names the when-not case with the two sibling alternatives. The routing condition ('for exact page text or a cheap lookup') is concrete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find wiki pages containing a word or phrase. Exact match, no AI tokens.
Use it to locate pages before reading them with get_page, or when
you need the team's exact wording. It matches text literally, so
for a plain-English question ("why did we drop Stripe?") use
query, which finds pages by meaning and writes a cited answer.
Returns up to limit hits as {category, name, title, snippet};
snippet is about 280 characters around the first match, fine to
show as a citation preview. An empty list means no page contains it.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Most hits to return, e.g. 10. Default 20; values below 1 count as 1 and above 50 as 50. | |
| query | Yes | Word or exact phrase to find in page names and text, matched case-insensitively as a plain substring (no AND/OR, no fuzzy match). Short is best, e.g. "refund policy" or "stripe". Blank returns no hits. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and largely meets it: literal/substring matching, deterministic behavior (no AI tokens), snippet size (~280 chars) suitable as a citation preview, and that an empty list means no match. It omits auth/rate-limit details and never explicitly states read-only, but for a search operation the key traits are disclosed.
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?
Purpose is front-loaded in the first sentence, and each paragraph adds a distinct piece of value (usage, return shape, empty-result meaning). Slightly paragraph-heavy for a two-parameter tool but nothing is 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?
Given an output schema exists, return values need not be explained, yet the description helpfully characterizes the snippet. Usage, match semantics, and empty-result interpretation are all covered; only minor gaps like pagination or escaping behavior remain.
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 100% and the schema already documents the substring/case-insensitive semantics and the limit clamping. The description's 'matches text literally' largely restates the schema rather than adding new syntax or format detail, so baseline 3 applies.
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?
States a specific verb and resource ('Find wiki pages containing a word or phrase') plus the discriminator 'Exact match, no AI tokens.' An agent can immediately distinguish it from query and get_page without opening any schema.
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?
Explicitly names both when to use it ('locate pages before reading them with get_page', 'need the team's exact wording') and when to prefer the sibling ('for a plain-English question ... use query'). The routing condition is spelled out, not inferred.
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.
get_page6 fields changedInput schema / properties / category / descriptionAdded value: +"String. The page's folder, from a ``list_pages`` or ``search_wiki`` result, e.g. \"concepts\". One of: entities, concepts, people, decisions, sources, flows, infrastructure, tickets, chats, mail, docs, conversations, schemas, skills. Default \"\": found from ``name``."Input schema / properties / name / descriptionAdded value: +"String. The page's ``name`` from ``list_pages`` or ``search_wiki``, without \".md\", e.g. \"billing-flow\". Default \"\"; give this or ``path``."Input schema / properties / page / descriptionAdded value: +"String. Same as ``name``; accepted for clients that send it. Default \"\"."Input schema / properties / path / descriptionAdded value: +"String. Category and name in one, e.g. \"concepts/billing-flow\"; use instead of ``category`` + ``name``. Default \"\"."Input schema / properties / slug / descriptionAdded value: +"String. Same as ``name``; accepted for clients that send it. Default \"\"."Input schema / properties / title / descriptionAdded value: +"String. Same as ``name`` (the page's name, not its display title); accepted for clients that send it. Default \"\"."get_skill1 field changedInput schema / properties / name / descriptionAdded value: +"The skill's ``name`` from ``list_skills``, e.g. \"cut-a-release\". Case, spaces and a trailing \".md\" are tidied for you. Required."impact2 fields changedInput schema / properties / depth / descriptionAdded value: +"How many call hops to follow out from the target, e.g. 3. Default 2; values below 1 count as 1. Higher finds more but returns a bigger result."Input schema / properties / target / descriptionAdded value: +"What you plan to change: a file path as ingested, e.g. \"micrograd/engine.py\"; a function as \"file::name\", e.g. \"engine.py::backward\"; or a graph node id or wiki page name. Required."list_proposed_actions1 field changedInput schema / properties / status / descriptionAdded value: +"Only return proposals in this state: \"proposed\" (waiting for a person), \"approved\", \"executing\", \"done\", \"failed\" or \"dismissed\", e.g. \"proposed\". Default \"\": every state. Any other value matches nothing."propose_action4 fields changedInput schema / properties / action_type / descriptionAdded value: +"Which kind of action to file, e.g. \"jira.create_issue\". One of: gcal.create_event, github.create_issue, gmail.create_draft, jira.create_issue, linear.create_issue, notion.create_page, slack.ask_teammate, slack.post_message, wiki.reverify_page, zendesk.internal_note. gmail.create_draft only saves a draft and never sends; wiki.reverify_page asks a person whether a wiki page is still correct. Required; an unknown value returns the valid list."Input schema / properties / description / descriptionAdded value: +"Optional body in Markdown: details, steps, links, e.g. \"Export fails after 30s for accounts with 50k+ rows.\" Default \"\"."Input schema / properties / evidence / descriptionAdded value: +"Optional note on why this is needed, such as a quote or a link to the Slack thread, e.g. \"Customer asked in #support on 3 Oct\". Shown to the person who approves. Default \"\"."Input schema / properties / title / descriptionAdded value: +"Short headline: the ticket or issue title, message summary or email subject, e.g. \"Fix CSV export timeout for large accounts\". Required."query2 fields changedInput schema / properties / model / descriptionAdded value: +"Optional AI model id to answer with, e.g. \"gemini-2.5-flash\", \"gpt-4o\" or \"claude-sonnet-4-5\"; the provider's key must be saved in Enhanciar. Default null: the saved default model (the workspace's in a team workspace, yours in a personal one)."Input schema / properties / question / descriptionAdded value: +"The question in plain English, one topic per call, e.g. \"Why did we move billing off Stripe?\" or \"Who owns the onboarding emails?\". Required."search_wiki2 fields changedInput schema / properties / limit / descriptionAdded value: +"Most hits to return, e.g. 10. Default 20; values below 1 count as 1 and above 50 as 50."Input schema / properties / query / descriptionAdded value: +"Word or exact phrase to find in page names and text, matched case-insensitively as a plain substring (no AND/OR, no fuzzy match). Short is best, e.g. \"refund policy\" or \"stripe\". Blank returns no hits."get_page9 fields changedInput schema / properties / category / defaultAdded value: +""Input schema / properties / category / typeRemoved value: -"string"Input schema / properties / name / defaultAdded value: +""Input schema / properties / name / typeRemoved value: -"string"Input schema / properties / pageAdded value: +{
+ "default": "",
+ "title": "Page"
+}Input schema / properties / pathAdded value: +{
+ "default": "",
+ "title": "Path"
+}Input schema / properties / slugAdded value: +{
+ "default": "",
+ "title": "Slug"
+}Input schema / properties / titleAdded value: +{
+ "default": "",
+ "title": "Title"
+}Input schema / requiredRemoved value: -[
- "category",
- "name"
-]get_graphget_pageget_process_mapget_skillimpactlist_pageslist_proposed_actionslist_reposlist_skillspropose_actionquerysearch_wikiEnd-to-end agent-managed company brain. Docs, diagrams, plans, databases, agents, Knowledge Graph.
The company brain for your AI agents: how your business works, from the systems you already use.
Your company's brain for AI agents. Cited, permission-aware knowledge across every system.
Your company brain: search decisions, people, customers and projects across connected sources.
Add one secure layer between your agents and this server.
