Enhanciar is a company brain for engineering teams. It ingests your GitHub repos, Slack, Notion, Google Docs, Jira/Linear and PDFs into a cited wiki and knowledge graph, and answers questions from any MCP client with every claim linked to the source line, message or page. Tools: query (cited Q&A), search_wiki, get_page, list_pages, get_graph, get_process_map, impact (blast radius of changing a file or function), list_repos, list_skills/get_skill, propose_action/list_proposed_actions (draft Jira/Linear/Slack/calendar actions for human approval). BYOK — bring your own model key. Early access: join the waitlist at https://enhanciar.in and create an API key in Settings.
Scored across 12 tools
Every tool has a distinct resource/action pair, and the descriptions give clear routing guidance. The only weak spot is get_graph vs. get_process_map, which both return high-level graph structures but are ultimately differentiated by knowledge structure vs. operational process.
Most tools follow a clear get_/list_/verb_noun pattern, making the surface predictable. A couple of outliers — impact and query — are slightly less conventional, but they are still readable and not misleading.
Twelve tools is well-scoped for a company-brain workspace: retrieval, search, graph/process views, skills, repo visibility, impact analysis, and action proposal each earn a place. No tool feels redundant or unnecessary.
The read-side brain surface is well covered: pages, search, semantic query, graph, process map, skills, repos, and impact. The main gaps are a lack of direct repo/file content retrieval and no create/update wiki operations, though those appear intentionally left to the UI or human approval workflow.
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.
| 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 are provided, so the description carries the behavioral burden. It clarifies that the tool is read-only in nature ('Return', 'for visualisation') and discloses the exact return shape ({nodes, edges, communities, stats}) plus its correspondence to the REST endpoint. For a zero-parameter retrieval tool, this is sufficient 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?
The description is three sentences with no filler: it states the action, gives the use case, and specifies the return shape. Each sentence adds necessary information, and the most important distinguishing detail is front-loaded.
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 that the tool takes no parameters and an output schema is reportedly available, the description covers everything an agent needs: what the tool does, when to use it, and what shape the result takes. There are no hidden inputs or ambiguous prerequisites.
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 has zero parameters, and the schema coverage is trivially 100%, so there is no parameter meaning for the description to add. The baseline of 4 applies because the description instead clarifies what the returned graph represents, which is the relevant semantic context for this tool.
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?
The description names a specific verb ('Return') and a clear resource ('community/knowledge graph manifest'), and it explicitly contrasts the graph-level view with 'the contents of any one page,' which distinguishes it from siblings like get_page and list_pages. The scope and purpose are immediately identifiable.
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?
The description states when to use the tool: when the agent wants the high-level workspace structure rather than page contents. It does not explicitly name alternative tools or list exclusions, but the 'rather than' phrasing gives enough contextual guidance for an agent to select this tool appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| category | Yes |
| 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 behavioral burden, and it discharges it by documenting the exact return shape ({category, name, content}), the content format (full markdown including YAML frontmatter), and the error behavior for missing pages. It does not explicitly state that this is read-only, but 'Fetch' plus return semantics make that a reasonable inference.
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?
The description is compact, front-loaded with the operation, then organized into Args and Returns sections. Every sentence contributes necessary information, with no filler or repetition of the schema.
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 two-argument fetch operation with no annotations, the description covers purpose, parameter values, input requirements, output format, and error behavior. The only absent context (e.g., permissions or rate limits) is not material for this tool's complexity.
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 0%, but the description fully compensates: category is given an explicit enum list and name is defined as a page slug without .md extension and provenance. The parameter meanings are clearer here than they would be in most machine-readable schemas.
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?
The description opens with a specific verb and object: 'Fetch a single wiki page from the key's workspace.' It clearly signals a single-item retrieve operation, distinguishing it from list/search/query siblings. The category and name arguments and return context make the purpose unambiguous.
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?
The description implies the correct usage context by requiring a name 'as returned by list_pages / search_wiki', which tells an agent what must happen before calling get_page. It does not explicitly enumerate when to choose this tool over the siblings or when not to use it, so it stops short of full exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| 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 are provided, so the description must disclose behavioral traits. It says 'Return' which implies a read-only operation, but it does not explicitly state that no data is modified, or mention authentication or rate limits. The description gives some insight into the return structure but does not fully cover potential side effects or constraints.
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?
The description is concise (three sentences) and well-structured: it opens with the core purpose, then details the graph content, and closes with explicit usage guidance. No filler or redundancy; every sentence adds value.
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 parameters and an output schema, the description is largely complete. It covers what the tool returns, the context in which it is used, and differentiates from related tools. A minor gap is that it does not clarify what 'key's workspace' refers to, but this is likely environmental context an agent already possesses.
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 has zero parameters, so there is nothing to explain. The schema coverage is trivially 100% and no parameter descriptions are needed. The description does not add parameter-specific semantics because there are none, aligning with the baseline for parameterless tools.
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?
The description explicitly states the tool returns a 'living map of how the company works' for the workspace, and specifies the exact components (process nodes, external systems, wiki docs, team groups) and edge types. This is a specific verb+resource that clearly differentiates from siblings like get_skill, which focuses on individual skill steps.
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?
It provides a clear usage context ('when the agent wants the high-level operational structure') and an implicit exclusion ('rather than one skill's steps'), but does not name an explicit alternative tool like get_skill or get_graph. The guidance is useful but lacks a direct pointer to a sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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).
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes |
| 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 full responsibility for behavioral disclosure. It specifies the return object shape ({name, markdown, meta}), explains what markdown and meta contain, and describes the error-key behavior with available names when the skill does not exist. The 'Fetch' verb also conveys a read-only operation.
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 sentences with the core operation front-loaded, followed by return shape and edge-case handling. Every clause adds necessary information, and there is no redundant or promotional language.
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 one-parameter read tool, the description covers purpose, identifier source, output structure, and not-found behavior. The presence of an output schema further reduces the need for additional return-value detail, so nothing essential 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 only parameter, name, has no description in the schema (0% coverage), but the description compensates by defining it as a slug from list_skills. This gives the agent concrete provenance for valid values, far beyond the bare schema title 'Name'.
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?
The description opens with a specific verb and resource: 'Fetch one compiled skill by name'. It also names the source of valid identifiers ('slug from list_skills'), which clearly distinguishes this tool from list_skills and other sibling tools.
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?
The phrase 'slug from list_skills' gives clear operational context: an agent should first call list_skills to get names before using get_skill. It does not explicitly name alternatives or state when not to use it, so it stops just short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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}.
| Name | Required | Description | Default |
|---|---|---|---|
| depth | No | ||
| target | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses a notable behavioral trait: there is deliberately no risk score, and it explains the rationale (previous thresholds were unverifiable). It also clarifies that the tool returns counts and paths for the caller to judge. Since no annotations are provided, the description carries the burden, and it does so well, though it could mention performance or side effects (e.g., whether it traverses the entire graph).
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?
The description is well-structured and front-loaded: it starts with the core purpose, then usage guidance, then a deliberate non-feature, then parameter details, then return format. Every sentence earns its place, and the return dict is listed compactly.
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 the tool's complexity (graph traversal, transitive analysis, path facts) and the presence of an output schema, the description is complete. It explains what the tool returns, how to invoke it, and what it intentionally omits. An agent has enough context to select and 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 0%, so the description must compensate. It does: it explains target accepts a graph node id, wiki page name, file path, or function fqn, and depth is the number of hops to traverse. This adds meaning beyond the bare schema types. It doesn't detail depth's exact range or default behavior beyond 'default 2', but that's a minor gap.
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?
The description clearly states the tool computes the blast radius of changing a target in the key's workspace, listing specific outputs like direct callers/callees, affected files, tests, transitive dependency set, and example paths. This distinguishes it from siblings like get_graph or query, which are more general graph or search tools.
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?
The description explicitly says 'Use this before editing code to see what a change ripples into,' giving a clear when-to-use directive. It also explains what the tool deliberately does not do (no risk score) and why, which helps an agent decide whether to rely on it for impact analysis versus other tools.
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 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.
| 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. It discloses that the result is a lightweight list of records, not full content; that it is filtered by caller visibility; and that it is scoped to the key's workspace. It does not mention pagination or ordering, but the output schema covers the record shape.
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 tight sentences with no filler: the main action comes first, then the return format and pipeline, then the usage guidance. Every sentence adds value.
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 listing tool with an output schema, the description is complete. It explains scope, record format, the obvious next step (get_page), and when to use query instead, so an agent can select and invoke 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 tool takes zero parameters, so the baseline of 4 applies. The description adds useful context about what each returned record enables (feeding into get_page), though no parameter-specific 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 precise verb and resource: 'List every wiki page the caller can see in the key's workspace.' This identifies what is returned and is clearly distinguishable from siblings like get_page, query, and search_wiki.
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 tells the agent when to use it ('Use this first when you want a directory view') and when to prefer an alternative ('for a specific question prefer query'). It also explains the get_page follow-up, leaving no ambiguity about the workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| status | No |
| 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 behavioral disclosure burden. It explicitly states "Read-only," lists the allowed statuses, specifies the returned field shape, and discloses the deliberate limitation that MCP cannot approve or execute actions. This is comprehensive behavioral transparency.
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?
The description is front-loaded with the essential purpose, then provides filter details, return shape, and the safety limitation in a compact, well-organized note. No sentence is wasted or redundant.
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 single-optional-parameter list tool with an output schema, the description is fully complete: it states what is listed, how to filter, what each result contains, and the behavioral constraints around approval/execution. Nothing necessary 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 description coverage is 0%, so the description must compensate. It does so by documenting the status parameter's allowed values (proposed / approved / executing / done / failed / dismissed) and explicitly marking it optional, which is exactly the meaning missing from 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?
The description opens with a specific verb and resource: "List the key's workspace's proposed actions (the approval queue)." This clearly identifies it as a read-only listing tool and distinguishes it from sibling tools like propose_action, which creates actions rather than listing them.
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?
The description provides clear usage context: it is for viewing the approval queue and optionally filtering by status. It does not explicitly name alternatives or exclusions, but the note that MCP cannot approve or execute actions gives practical guidance on what this tool cannot do.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| 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 present, the description fully carries the behavioral disclosure burden. It reveals exactly what is read (repos.json, per-repo _state files), explains the historical Firestore bug and why it was wrong, and clarifies why the field is named branch rather than default_branch. This is far beyond a typical 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?
The description is front-loaded with the core purpose, but the second half is a lengthy historical explanation about the Firestore bug and field-name rationale. While informative, it could be trimmed significantly; the narrative about 'wrong twice over' and returning an empty list to everyone is not essential for correct tool invocation.
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 tool with an output schema and no annotations, the description is complete. It states the namespace scope, data sources, and why certain data appears, leaving no operational ambiguity for an agent.
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 has zero parameters, so the baseline is 4. The description correctly implies no arguments are needed and instead focuses on the behavior and output, which adds value beyond the empty 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?
The first sentence names a specific verb and resource — listing repos for the key's workspace — and specifies the return record shape. It clearly differs from sibling list tools like list_pages and list_skills, so an agent can select it correctly.
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?
The description gives an explicit use case: 'Use this when the agent needs to know what context is available before asking a question.' It does not name sibling alternatives or exclusion conditions, but the context is clear enough to guide selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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).
| 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 provided, the description carries the full burden and discloses key behavioral aspects: it identifies the output format (records with specific fields), clarifies that results are compiled from the workspace's wiki, and explains the empty-list behavior with a remedy (run a compile). This goes beyond minimal and gives actionable insight.
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?
The description is concise (three sentences) and front-loaded with the core purpose. Each sentence adds value: purpose, output details, and a note on empty results. No fluff or redundancy—textbook efficiency.
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 the tool's simplicity (no parameters) and the presence of an output schema, the description is complete. It explains what the tool does, what it returns, and how to handle empty results. An agent can confidently invoke it without further clarification.
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 has no parameters, so there is no schema to describe. The description still adds value by explaining the output structure (fields like name, title, description) and how to proceed with results (feed name to get_skill), which is helpful context even though no parameters exist.
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?
The description clearly states the tool lists compiled skills (recurring procedures) in the key's workspace, identifying the resource and action with specificity. It distinguishes itself from siblings like get_skill (which retrieves full markdown) and other list tools (e.g., list_pages) by focusing on compiled skills from the wiki.
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?
The description provides context on when to use it (to view compiled skills) and hints at alternatives (e.g., get_skill for full markdown, running a compile if empty). However, it doesn't explicitly state when not to use it or compare with related tools like list_pages or search_wiki, but the context is sufficient for basic differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | ||
| evidence | No | ||
| action_type | Yes | ||
| description | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It openly states the tool does not execute, describes the approval queue flow, and specifies the return value structure ({id, action_type, status}) or an error. This is transparent about the async and non-authoritative nature, though it could add more context about error conditions or queue status.
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?
The description is concise, with three sentences that front-load the key point (no execution) and provide necessary context. It avoids repetition and wastes no words. Slightly verbose in the parameter explanation, but overall well structured.
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 that the tool has an output schema and a clear description of workflow, the description is complete enough for an agent to call it correctly. It covers the non-execution aspect, the approval queue, the return format, and the action_type registration. It does not mention prerequisites or permissions, but these are not critical for basic invocation.
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 0%, so the description must compensate. It thoroughly explains action_type with concrete examples (jira.create_issue, etc.), but does not elaborate on the meaning of title, evidence, or description parameters. While title and description are likely self-explanatory, evidence remains ambiguous without guidance. Partial compensation only.
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?
The description clearly states the verb ('Propose') and resource ('a new action'), and explicitly notes it 'does NOT execute it'. It also differentiates from related tools by explaining that approve/execute are intentionally not exposed over MCP, making the tool's purpose unambiguous even among 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?
The description clearly explains that the action lands in an approval queue for human review, and that execution is not possible through MCP. This gives strong contextual signals on when to use the tool. However, it does not explicitly name an alternative tool for direct execution, though it implies such tools exist outside MCP.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | ||
| question | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does so excellently. It discloses the retrieval + synthesis pipeline, the return structure ({answer, sources, model}), the nature of the citations, and an important edge case: an empty workspace yields {answer, empty_brain: true} with no sources, which is a statement about the workspace rather than a failed search. This anticipates misinterpretation and guides the agent's next action.
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?
The description is front-loaded with the primary purpose, then organized into usage, arguments, and return behavior. Every sentence adds value: no filler, no repetition of schema names, and the important empty-brain caveat is placed at the end where it serves as a critical clarification.
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?
The tool has only 2 parameters (1 required) and an output schema, and the description covers both parameter semantics and return values thoroughly. It also handles the non-obvious empty-workspace case, making it complete for an agent to select and invoke the tool correctly without further context.
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 0%, but the description compensates fully. It defines 'question' as a natural-language question and explains 'model' as an optional override with concrete examples (gemini-2.5-flash, gpt-4o, claude-sonnet-4-5) and the default-selection behavior for team vs. personal workspaces. This adds meaning far beyond the bare 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?
The description opens with a specific verb and resource: 'Ask Enhanciar a natural-language question grounded in the key's workspace.' It further clarifies scope with concrete examples ('what does X do', 'why did we choose Y') and frames itself as 'the high-level tool' running the full retrieval + synthesis pipeline, distinguishing it from the more specific sibling tools like get_page, get_skill, and search_wiki.
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?
It gives clear when-to-use guidance: 'use it for any what does X do / why did we choose Y / where is Z handled question.' It also explains that it is the high-level tool vs. lower-level siblings, but it does not explicitly name alternatives or state when not to use it, so it falls just short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the search is substring-based, deterministic, returns up to 'limit' hits with a snippet window, and notes the snippet is safe for citation preview. It doesn't cover error handling or pagination beyond the limit, but the provided behavioral details are solid.
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 sentences with no redundancy. The purpose is stated first, followed by constraints and the alternative guidance. Every sentence adds value.
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?
The tool has an output schema, and the description explains the return format and snippet semantics. It also covers usage guidance and parameter constraints. Nothing essential for correct invocation is missing for a search tool with two parameters.
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 0%, so the description must add meaning. It explains the 'limit' parameter (default 20, max 50) and implicitly defines 'query' as the substring to search. It also details the output fields (category, name, title, snippet), exceeding schema information.
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?
The description explicitly states it performs substring search across wiki pages and names the sibling tool 'query' as the alternative for semantic questions. This clearly distinguishes it from siblings and gives a specific verb and resource.
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?
It provides explicit when-to-use guidance ('Cheap and deterministic — no embedding required') and explicitly directs users to prefer 'query' for natural-language questions, giving both an exclusion and an alternative.
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_graphget_pageget_process_mapget_skillimpactlist_pageslist_proposed_actionslist_reposlist_skillspropose_actionquerysearch_wikiYour company's brain for AI agents. Cited, permission-aware knowledge across every system.
End-to-end agent-managed company brain. Docs, diagrams, plans, Knowledge Graph. Lean & affordable.
Cloud or self-hosted knowledge for AI agents: hybrid search, reranking, GraphRAG, scoped MCP tools.
Shared memory for coding agents and their teams: project docs with semantic search, plus epics, tasks, open questions and decisions your agent reads and writes over MCP. Teammates and their agents share the same board. Deploy and permanent delete stay human-only and are enforced by the server. Free tier, no card. Setup: https://app.bilgai.com/docs/connect — API key (blg_) as Bearer or OAuth. Issues: https://github.com/volkansuner/bilg-feedback
Add one secure layer between your agents and this server.
