Skip to main content
Glama

Cross-Pollinate Knowledge

engram_cross_pollinate
Read-onlyIdempotent

Reuse a lesson solved in another repository before rebuilding a shared pattern. Unlike engram_recall or engram_smarter, this explicitly excludes target_repo from source searches and adds transfer lessons and quality gates. Returns Markdown with ranked memories and source repos from other authenticated workspace repositories, with optional public knowledge.

source_repos restricts the search; include_public supplements sparse private results. Records retrieval telemetry without copying knowledge. Consumes workspace daily call quota. OAuth: memory:read.

Input Schema

NameRequiredDescriptionDefault
depthNoDefault focused uses a small retrieval budget; deep expands it when focused results are insufficient. An explicit limit overrides the default budget.
limitNoMaximum retrieved memories, 1–25. Omitted defaults: focused=5, deep=12; explicit values override these defaults.
contextYesNatural-language task and relevant facts, e.g. migrate our PostgreSQL schema with zero downtime. Never include credentials or raw customer data.
session_idNoExact journal id from start/rehydrate/list_sessions. Disambiguates parallel work; writing requires your active session. Rehydrate may read shared or closed history.
target_repoYesDestination repository slug for the current work; memories from this repo are excluded from the source search.
source_reposNoRestrict source repositories to these slugs; omit or pass an empty array to search other repositories.
include_publicNoDefault true: supplement private results with public knowledge when needed. False searches only other private workspace repositories.

Output Schema

NameRequiredDescriptionDefault
textYesThe same bounded payload as content[0].text; interpret it using format. JSON text contains the endpoint-specific fields described by this tool.
formatYesPayload encoding: Markdown context/checkpoint, serialized JSON data, or plain confirmation text.
truncatedYesTrue when the payload exceeded 120,000 characters and was cut with a notice. Narrow the request; truncated JSON is not parseable.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / session_id
      Added value: +{
      +  "description": "Exact journal id from start/rehydrate/list_sessions. Disambiguates parallel work; writing requires your active session. Rehydrate may read shared or closed history.",
      +  "type": "string"
      +}
  2. Changed8 schema fields changed
    • addedInput schema / properties / context / description
      Added value: +"Natural-language task and relevant facts, e.g. migrate our PostgreSQL schema with zero downtime. Never include credentials or raw customer data."
    • addedInput schema / properties / depth / description
      Added value: +"Default focused uses a small retrieval budget; deep expands it when focused results are insufficient. An explicit limit overrides the default budget."
    • addedInput schema / properties / include_public / description
      Added value: +"Default true: supplement private results with public knowledge when needed. False searches only other private workspace repositories."
    • addedInput schema / properties / limit / description
      Added value: +"Maximum retrieved memories, 1–25. Omitted defaults: focused=5, deep=12; explicit values override these defaults."
    • addedInput schema / properties / source_repos / description
      Added value: +"Restrict source repositories to these slugs; omit or pass an empty array to search other repositories."
    • addedInput schema / properties / source_repos / items / description
      Added value: +"Source repository slug in this workspace."
    • addedInput schema / properties / target_repo / description
      Added value: +"Destination repository slug for the current work; memories from this repo are excluded from the source search."
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "$schema": "http://json-schema.org/draft-07/schema#",
      +  "additionalProperties": false,
      +  "properties": {
      +    "format": {
      +      "description": "Payload encoding: Markdown context/checkpoint, serialized JSON data, or plain confirmation text.",
      +      "enum": [
      +        "markdown",
      +        "json",
      +        "text"
      +      ],
      +      "type": "string"
      +    },
      +    "text": {
      +      "description": "The same bounded payload as content[0].text; interpret it using format. JSON text contains the endpoint-specific fields described by this tool.",
      +      "type": "string"
      +    },
      +    "truncated": {
      +      "description": "True when the payload exceeded 120,000 characters and was cut with a notice. Narrow the request; truncated JSON is not parseable.",
      +      "type": "boolean"
      +    }
      +  },
      +  "required": [
      +    "text",
      +    "format",
      +    "truncated"
      +  ],
      +  "type": "object"
      +}
  3. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive/closed-world, and the description adds genuinely new operational facts: it records retrieval telemetry without copying knowledge, consumes the workspace daily call quota, and requires the memory:read OAuth scope. Quota consumption and auth scope are exactly the behavioral traits annotations cannot express.

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?

Purpose and sibling differentiation are front-loaded, followed by parameter semantics and operational constraints. It is dense and jargon-heavy ('transfer lessons and quality gates'), but every sentence carries information and nothing is repeated from the schema or annotations.

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?

With an output schema present, return values need not be re-explained, and the description still notes the Markdown/ranked-memory shape. Annotations cover the safety profile, the schema covers all 7 parameters, and quota, auth, and telemetry are disclosed — nothing an agent needs to call this correctly is missing.

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 real semantic value beyond the schema: target_repo memories are excluded from the source search, source_repos restricts rather than expands scope, and include_public supplements sparse private results. These clarify the interaction between parameters that the schema describes only individually.

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 opening sentence states a specific verb and resource ('Reuse a lesson solved in another repository') and names the two sibling tools it differs from (engram_recall, engram_smarter). An agent can tell exactly what this tool does and how it differs from the closest alternatives without opening a schema.

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

Usage Guidelines4/5

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

The trigger condition ('before rebuilding a shared pattern') and the explicit contrast with engram_recall/engram_smarter give clear context for selection. It stops short of stating when to prefer recall or smarter over this tool, so the routing is implied rather than fully enumerated.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources