Skip to main content
Glama

get_relevant_context

Read-onlyIdempotent

Searches the team's Marcora context library and returns up to 10 passages most relevant to a prompt, plus sources (each with a link_url) for citing. Read-only.

When to use:

  • The user wants writing grounded in their team's brand or company context (blog post, email, social post, landing page, ad): call this with include_brand_foundation: true and write it yourself from what it returns. If asked to save it, use create_content content.

  • The user asks about their own company, product, positioning, launches or competitors ("what do we have on competitor X?"): call it and answer from their context.

  • Before saving text you wrote yourself through create_content / update_content content: those store it verbatim and consult no context.

When NOT to use:

  • Before create_content with instructions (Marcora writes): it gathers the context itself.

  • For brand voice, company overview, writing style or writing examples on their own: relevancy search never returns Brand Foundation. Use get_brand_foundation, or set include_brand_foundation: true here.

Inputs:

  • prompt (required): what you need; be specific.

  • include_brand_foundation: true on the FIRST call of a conversation (adds company overview, brand voice, style and examples); false or omitted after.

  • include_only_me: true also searches the user's own Only me items (never another member's).

  • project_id: adds that project's items and, on the first call, returns its project_brief. Read the brief before drafting: it outranks older chunks. Set include_project_brief: false on later calls for the same project.

  • collection_ids and project_id broaden the search (additive, never an exclusive filter); dimension_option_ids biases toward an audience, persona or industry; context_rag_ids excludes chunks already returned when you page for more.

Present each link_url exactly as returned.

How results are ranked: each passage is scored on its own and against the whole document it belongs to, and the two scores are blended; weak matches are dropped, so fewer than 10 can come back. dimension_option_ids lean the ranking toward the chosen audience, persona or industry. It searches the reference library plus the project, collections and shared collections the user can access.

Only me items: by default only Team items are searched. With include_only_me: true the user's own Only me items, including Only me calls, are searched too, never another member's. Calls filed in Calls come back only when that Calls collection's id is in collection_ids, or through their project; on its own include_only_me: true returns none of them. If you then write material you read from an Only me source into a team-visible document, the write is refused until the user agrees.

Calls window: calls adds calls to the search: { date_from, date_to, kinds, companies }, every field optional (dates as YYYY-MM-DD or ISO 8601; kinds from customer, external, team_meeting, one_on_one, recorded; {} is every call you may use). Each call carries its date, kind and company in its heading. Only Team calls come back, never a teammate's Only me call; include_only_me: true adds your own Only me calls. A Team call filed in a private project or private collection is treated like an Only me call: its source carries audience: "only_me".

Sources: each sources entry carries the item name, content_type, audience (team or only_me), a link_url deep-link that opens the item in the Marcora web app (plus source_url, the original external page URL, for webpage items), its collection_id / project_id / last_updated, and the context_rag_ids from that item. Use these to cite or link the material you surface. (The previous top-level context_item_ids field has been replaced by sources; each source's context_item_id gives you the same IDs.)

Project brief: with project_id, the response carries a top-level project_brief block: the project's authoritative statement of premise, scope and the structural decisions already taken. It is the same block get_project returns (content_id, name, word_count, content_intro, truncated, read_first). Read it before drafting, revising, assessing or critiquing anything in the project; context chunks may be older than the brief or contradict it, and the brief wins. When truncated is true, content_intro is only the opening excerpt, so call get_content with its content_id for the full text. The brief is stored as content, not as a context item, so relevancy search never surfaces it: this block is the only way it reaches you from this tool. The key is absent when the project has no brief. include_project_brief defaults to true and is ignored without project_id.

Brand Foundation bundling: include_brand_foundation: true returns the team's Brand Foundation (company overview, brand voice, writing style, writing examples) in the same response. It is the always-on foundational context relevancy scoring never surfaces on its own. Pull it once, up front, so you have it for the rest of the session; you don't need it when handing off to create_content with instructions, which pulls it in automatically.

Errors when you pass project_id: "Project not found" means the project doesn't exist or belongs to a team other than your active team (check list_projects, or set_active_team if it is in another team). "You are not a member of project " means the project is private and you are not a member: ask a member to add you, or search without project_id. Neither error returns any context or brief.

Links: copy link_url character for character. Never retype, shorten, or rebuild a link or the IDs inside it.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "prompt": "<prompt>"
    },
    "name": "get_relevant_context"
  }
}

Input Schema

NameRequiredDescriptionDefault
callsNoAlso search the team's calls. Optional filters: date_from / date_to (YYYY-MM-DD or ISO 8601, compared with the call's own date), kinds, companies. Pass {} for every call you may use. Only Team calls unless include_only_me is true.
promptYesSearch prompt describing the topic / question you want context on. Be specific (e.g. "competitor X's pricing model" rather than "competitors").
project_idNoOptional project UUID (from list_projects). Additive: ALSO searches that project's context alongside your general library — not an exclusive filter.
collection_idsNoOptional context collection IDs (from list_context_collections). Additive: ALSO searches those collections alongside your general library — not an exclusive filter.
context_rag_idsNoOptional list of previously-returned chunk IDs to exclude (for pagination — pass back the context_rag_ids from a prior call).
include_only_meNoDefault false: only Team items are searched. Set true to also search your own Only me items, including Only me calls; never another member's. Calls filed in Calls come back only when that Calls collection's id is in collection_ids, or through their project; on its own, true returns none of them. Only me results carry audience: only_me. If you then write what you read into a team-visible document, you are asked first.
dimension_option_idsNoOptional targeting dimension OPTION IDs (from list_targeting_dimensions) to scope the search by audience / persona / industry / etc.
include_project_briefNoDefault true. When project_id is given, also return that project's brief as a top-level project_brief block. Leave true on the first call for a project in a conversation; set false on later calls for the same project so the brief isn't re-sent. Ignored when project_id is omitted.
_frontend_realtime_keyNoFor frontend progress updates only. Do not use from MCP clients.
include_brand_foundationNoSet true to also include the team's Brand Foundation in the response. Default false.

Output Schema

NameRequiredDescriptionDefault
sourcesNoOne entry per parent context item the returned chunks came from.
next_stepNoPresent only with workspace_status "empty": how to offer the user to set up their workspace. Save nothing without their OK.
project_briefNoPresent only when project_id is given, include_project_brief is true (the default) and the project has a brief; absent otherwise. The same block get_project returns: the project's authoritative statement of premise, scope and structural decisions. READ IT FIRST: the context chunks in this response may be older than it or contradict it. content_intro is an excerpt (the full body when the brief is short, otherwise the opening ~400 words with truncated: true); pass content_id to get_content for the full text.
context_rag_idsNoAll chunk IDs returned. Pass back in context_rag_ids to exclude from future searches (pagination).
brand_foundationNoAlways present. elements is null unless include_brand_foundation is true.
message_for_userNoPresent only with workspace_status "empty": plain text written to the user that says the workspace is empty and offers to set it up. Pass it on in your reply as it is. It is an offer: save nothing without their OK.
relevant_contextNoReady-to-use markdown context packet assembled from the matched chunks.
workspace_statusNoPresent only when the workspace is empty: no Brand Foundation and no reference library items yet.
brand_foundation_buildNoPresent only while Marcora is building the team's blank Brand Foundation sections (they are in progress, not empty). Absent otherwise, so never imply a build is running without it.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • addedInput schema / properties / calls
      Added value: +{
      +  "additionalProperties": false,
      +  "description": "Also search the team's calls. Optional filters: date_from / date_to (YYYY-MM-DD or ISO 8601, compared with the call's own date), kinds, companies. Pass {} for every call you may use. Only Team calls unless include_only_me is true.",
      +  "properties": {
      +    "companies": {
      +      "description": "Only these companies.",
      +      "items": {
      +        "type": "string"
      +      },
      +      "type": "array"
      +    },
      +    "date_from": {
      +      "description": "From this date (YYYY-MM-DD).",
      +      "type": "string"
      +    },
      +    "date_to": {
      +      "description": "Up to this date (YYYY-MM-DD).",
      +      "type": "string"
      +    },
      +    "kinds": {
      +      "description": "Only these kinds.",
      +      "items": {
      +        "enum": [
      +          "customer",
      +          "external",
      +          "team_meeting",
      +          "one_on_one",
      +          "recorded"
      +        ],
      +        "type": "string"
      +      },
      +      "type": "array"
      +    }
      +  },
      +  "type": "object"
      +}
    • addedInput schema / properties / include_only_me
      Added value: +{
      +  "default": false,
      +  "description": "Default false: only Team items are searched. Set true to also search your own Only me items, including Only me calls; never another member's. Calls filed in Calls come back only when that Calls collection's id is in collection_ids, or through their project; on its own, true returns none of them. Only me results carry audience: only_me. If you then write what you read into a team-visible document, you are asked first.",
      +  "type": "boolean"
      +}
    • addedOutput schema / properties / sources / items / properties / audience
      Added value: +{
      +  "description": "Who can see this item: team, or only_me (yours alone; returned only when include_only_me is true).",
      +  "enum": [
      +    "team",
      +    "only_me"
      +  ],
      +  "type": "string"
      +}
    • changedOutput schema / properties / sources / items / required
      Previous value: -[
      -  "context_item_id",
      -  "context_rag_ids"
      -]New value: +[
      +  "context_item_id",
      +  "audience",
      +  "context_rag_ids"
      +]
  2. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, but the description goes well beyond: blended per-passage and per-document ranking with weak-match dropping, Team vs Only me visibility, private-project calls being downgraded to audience 'only_me', write-refusal on Only me sources, and the two specific project_id error messages. This is materially useful behavior an agent cannot get from structured fields.

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

Conciseness3/5

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

Well front-loaded and organized with bold section headers, but at roughly a thousand words it is oversized for a 10-parameter tool. The 'Only me items', 'Project brief', and 'Calls window' sections largely re-narrate text already present verbatim in the input schema, and the link-fidelity instruction is stated twice ('Present each link_url exactly as returned' and 'copy link_url character for character').

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?

Despite an output schema already existing, the description still explains the `sources` shape, the `project_brief` block including its `truncated` fallback to get_content, and failure modes. Nothing an agent needs in order to call this correctly — or to recover from an error — 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 baseline is 3, and the description does add real meaning: `include_brand_foundation` only on the first call of a conversation, `include_project_brief: false` on later calls for the same project, `context_rag_ids` as a pagination token, and the additive (never exclusive) nature of `collection_ids`/`project_id`. It mostly restates the schema's own parameter descriptions, which caps it at 4 rather than 5.

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?

Opens with a specific verb and resource — 'Searches the team's Marcora context library and returns up to 10 passages most relevant to a prompt' — plus the return shape ('sources' with link_url). It explicitly distinguishes itself from get_brand_foundation and create_content, so an agent can place it among 60+ siblings 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 Guidelines5/5

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

Provides an explicit 'When to use' block with three concrete scenarios and a 'When NOT to use' block naming the alternatives (create_content with `instructions`, get_brand_foundation). The condition that selects each path is stated, not inferred.

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