Skip to main content
Glama
Sign In

Engramic

by ai.engramic.api
OverviewDiscussionsAdmin

Search Engramic

engramic_search
Read-only

Find topics, timeline events AND artefacts by matching text in their labels, details or content. Use for term-driven lookup when you have specific keywords or concepts in mind.

WHAT IT SEARCHES:

  • Topics: graph nodes (concepts, goals, constraints, gaps).

  • Events: the timeline — recorded decisions, discoveries, actions, and plain events. This means prior decisions and resolutions on a subject surface here, not just topic names.

  • Artefacts: the workspace's outputs (documents, decks, PDFs, web pages), matched on their name and the text of their latest version.

The response separates the three: topics (graph nodes), events (timeline hits, each with its type, subtype, occurredAt, and the topicIds it belongs to) and artefacts (outputs, each with its type and latest version). Check events when you need what was decided or discovered about something, not just whether a topic for it exists.

RESULTS ARE SNIPPETS, NOT FULL BODIES: Each hit carries a short snippet — a plain-text excerpt of its detail — NOT the complete body. This keeps results scannable. When a hit warrants the full detail, DRILL IN:

  • Topics: call engramic_topic with the hit's id to read its complete detail.

  • Events: call engramic_event with the hit's id to read the full event, complete detail included.

  • Artefacts: call engramic_artefact with the hit's id to read its text, sources and links.

SEARCH vs BROWSE:

  • engramic_search: you have a term, concept name, or keyword to look up

  • engramic_topic: you want to explore the graph structure, see what's under a domain, or are unsure how something is labelled

WHEN BOTH APPLY — prefer engramic_search first. If results are weak or ambiguous, fall back to engramic_topic to browse the structure. If search and topic disagree on where something lives, trust engramic_topic — it reflects the actual graph structure; search is content-matched and may surface stale or partial matches.

QUERY GUIDANCE:

  • Be specific: "PostgreSQL migration" not "database stuff"

  • Multi-word queries use OR logic — "backup recovery" matches items containing either word

  • Try alternative terms or synonyms if initial results are weak

  • Use parentId to search within a specific branch of the graph instead of globally

  • Narrow results with filters when they're too broad:

    • type (concept, constraint, goal, gap) to target a topic knowledge category, or artefact for artefacts (outputs) only

    • status (not_started, in_progress, achieved, etc.) to filter topics by lifecycle state

    • overdue (true) to find goals past their deadline that haven't been achieved or abandoned

    • maxClassification to respect information sensitivity boundaries NOTE: filters are topic-structural — applying any of them scopes results to topics only (events and artefacts carry no lifecycle/classification of their own).

Use search results to drill deeper with engramic_topic or to confirm topics before engramic_record_draft.

Input Schema

NameRequiredDescriptionDefault
typeNoFilter by topic type, or "artefact" for artefacts (outputs) only
limitNoMaximum results to return (default: 20)
queryYesSearch query for topics
statusNoFilter by knowledge lifecycle status (e.g., in_progress for goals, active for constraints, open for gaps)
overdueNoShorthand: find goals past their validUntil deadline with non-terminal status. Overrides type and status filters when true.
parentIdNoFilter by parent: null=roots only, ID=children of that topic
maxClassificationNoMaximum classification level to include (filters out topics above this level)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the readOnlyHint and openWorldHint annotations, the description discloses key behavior: results are snippets rather than full bodies, the response separates topics, events, and artefacts, and each hit type has a specific drill-in tool. It also warns that search is content-matched and may surface stale or partial matches, which is valuable operational context not present in annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with purpose and uses clear headings for what it searches, result behavior, search vs browse, and query guidance. It is long, but most length is justified by the multi-entity search and seven parameters; some repetition about snippets and drill-in prevents a top score.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, so the description must explain return values, and it does: the response separates topics, events, and artefacts, and hits contain snippets rather than full bodies. It also explains how to retrieve full details and how filters affect scope, making the definition complete for this complex search tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds meaningful semantics beyond the schema: multi-word queries use OR logic, parentId searches within a graph branch, and filters have structural implications. There is a minor imprecision in saying applying any filter scopes results to topics only, since type=artefact is also a filter, but the parameter guidance is still substantially enriched.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource set: find topics, timeline events, and artefacts by matching text in labels, details, or content. It also explicitly distinguishes term-driven lookup from browsing the graph via engramic_topic, so an agent can select it without opening sibling schemas.

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

Usage Guidelines5/5

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

It gives explicit when-to-use guidance: use engramic_search when you have a keyword or concept, use engramic_topic when exploring structure or unsure of labelling. It also specifies what to do when both apply, including preferring search first, falling back to topic browsing, and trusting topic over search if they disagree.

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

All Engramic toolsInspect
Try in Browser
Context All Your Agents Can ShareAgents share what they learn, hand off work, and hold it when you switch models. Start with 5 GB free.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources