Ground an agent in your own knowledge
“Before you answer, recall what we know about our refund policy and cite the pages.”
list_sources → recall → read_doc
Model Context Protocol connector
Knowledge and memory for your agentic workflows, as native MCP tools. Any MCP client — Claude, Cursor, Cline, Windsurf, Zed — gets hybrid Graph RAG recall over your own corpus, and writes back what it learns so the next run starts smarter.
MCP server URL
https://tpsreport-mcp-customers-325927718367.us-central1.run.app/mcp This is the whole address — one endpoint for every workspace, white-label tenants included. Your credential decides which workspace you land in. Setup per client is below.
It is a Model Context Protocol server that connects any MCP-aware agent to your TPS Report workspace. The agent can search your knowledge base, read exact pages, author and publish new ones, and record what it learned — all as ordinary tool calls, with nothing to install locally.
Retrieval alone makes an agent well-read for one session. The write-back half is what makes a workspace improve: a learning recorded at the end of a run is a real, Git-versioned page a human can edit, and it is re-indexed so the next run recalls it. Most “memory” features are a conversation buffer. This is a corpus.
The consequence worth naming: your client holds one credential and nothing else — no corpus copy, no other tenant's data, no way to widen its own reach. Which workspace you reach is resolved server-side on every call, against your real memberships.
get_memory_directive() —What should I be watching for in this workspace, and where do learnings go?recall(subject) —What do we already know about this? Your corpus, not the open web.remember(kind, subject, learning) —The learning is written back as a typed, metadata-rich page.recall(subject) —Finds it. The substrate is better than it was yesterday.The directive itself is a normal page in your workspace. Edit it in the editor — change the objective, the capture rules, the routing — and every agent picks up the new policy on its next session. Memory driven by an objective, not by token pressure.
17 tools across 8 groups — the whole workspace, callable directly.
Optional arguments are marked ?; anything shown with = is the server-side
default, so you only pass it to override.
Who am I connected as, and what is this workspace asking me to watch for?
| Tool | Arguments | What it does |
|---|---|---|
whoami | — | Verify the key or token and return the user, account, and workspace it resolves to. The first call when a connection looks wrong. |
get_memory_directive | — | The workspace memory policy — what to capture this run and where each kind of learning routes. Auto-provisions the Agent Memory report on first call. |
Hybrid Graph RAG over your corpus — not the open web.
| Tool | Arguments | What it does |
|---|---|---|
recall | query, limit=5, report_path?, source_type?, tags[]?, intents[]?, keywords[]? | Metadata pre-filter, then vector + BM25 together, fused and reranked. Filters sharpen results dramatically — read list_sources first to learn which facets exist. |
list_sources | source_type? | Manifest of searchable sources with the tags, intents, and keywords each one carries. Read it before choosing recall filters. |
When you already know which page you want, do not search for it.
| Tool | Arguments | What it does |
|---|---|---|
list_reports | limit=20, sort_by="updated" | Reports with title, path, tags, and section counts. sort_by takes updated, created, or title. |
get_tree | report_path, max_depth=10, include_guidance=false | One report’s full outline — the sections and pages, with the exact paths read_doc and write_doc expect. |
read_doc | path | One page by exact node path, e.g. "my-report/Setup Guide/Install". Deterministic, no search involved. Returns the version number write_doc locks against. |
The half that makes the corpus compound instead of going stale.
| Tool | Arguments | What it does |
|---|---|---|
remember | learning, kind="reflexion", subject?, title?, agent?, confidence?, tags[]?, keywords[]?, entities[]?, hyde_questions[]?, report_path?, section? | Record a typed learning — reflexion, error_pattern, preference, fact, or insight — as a real, metadata-rich page the next run recalls. |
Write pages the way a human would, with the same safety rails.
| Tool | Arguments | What it does |
|---|---|---|
create_page | parent_path, title, content="", node_type="page" | Add a node under a parent: "page" for a content leaf, "section" for a container. Returns the new path. |
write_doc | path, content, commit_message?, expected_version? | Overwrite an existing page. Git-committed and flagged for re-index. Pass expected_version from read_doc to make a concurrent edit conflict instead of clobber. |
The metadata contract is checked server-side, before anything lands.
| Tool | Arguments | What it does |
|---|---|---|
validate_folder | folder, exclude[]? | Run the metadata gatekeeper over a local folder and write nothing. Errors block a clean sync; warnings are advisory. Same contract as the local linter. |
publish_report | title, folder?, description?, tags[]?, access_level="author", edit_scope="author", rag_enabled=false, collection_scope="user" | Create a new report to sync into and return its report_id. Pass folder to write the folder→report mapping into that folder’s .tps_sync.json sidecar. |
Move markdown in and out — the same reconcile the Obsidian plugin runs.
| Tool | Arguments | What it does |
|---|---|---|
push_folder | folder, report_id?, apply_deletes=false, exclude[]? | Push a folder of markdown into a report, node_id-first. Subfolders become sections; 00-INDEX.md becomes an index node. Omit report_id to read it from the sidecar. |
pull_report | report_id, dest_folder, overwrite=false | Materialize a report as local markdown with frontmatter and sync bookkeeping stamped, so a later push reconciles instead of duplicating. |
Stop improvising — author to the workspace’s standard.
| Tool | Arguments | What it does |
|---|---|---|
get_authoring_playbook | — | The authoring recipe — scope → seed → enrich → validate → publish → iterate — plus the exact frontmatter contract validate_folder enforces. Served inline, nothing installed. |
list_skills | — | The full skill packages this connector serves, with file counts and sizes. |
get_skill | name | One complete package — SKILL.md, references, and scripts including the deterministic linter — ready to write into your host’s skills directory. |
Two calls carry the rest: get_memory_directive tells the session what this workspace
wants remembered, and get_authoring_playbook tells it how to write. Start there and
the other fifteen sequence themselves.
“Before you answer, recall what we know about our refund policy and cite the pages.”
list_sources → recall → read_doc
“That build failure again — check whether we have hit it before.”
recall(kind: error_pattern) → fix → remember
“Draft the integration guide as a new report, then validate it before I look.”
get_authoring_playbook → create_page → write_doc → validate_folder
“That report is ready — publish it.”
publish_report
“Push my whole docs/ folder into the Handbook report.”
validate_folder → push_folder
“Install the authoring skill and work to that standard.”
list_skills → get_skill
Yes — including white-labelled ones. There is a single endpoint for the entire workspace universe, and which workspace you land in is decided by your credential, never by which URL you were given.
A tool is a button. A skill is the operating manual. list_skills and get_skill hand your session complete skill packages — instructions, references, and
scripts — so it authors to the workspace’s standard instead of improvising. Nothing is cloned and
nothing is installed on your machine.
If you would rather keep the session thin, get_authoring_playbook and validate_folder give you the same how-to and the same quality gate server-side, with
no local scripts at all.
Roadmap, not shipped. Everything above this section is live today. These are the next steps, published so you can judge the direction.
The sign-in flow already routes you to the right workspace across separate identity projects. The next step is making that page carry the workspace’s own branding rather than the platform’s.
The memory policy is a page you edit, so routing rules are already yours to change. The direction is finer control over which learnings land where, and when they expire.
Point any MCP client at:
https://tpsreport-mcp-customers-325927718367.us-central1.run.app/mcpAdd it as a custom connector and sign in. You are asked where your account lives and, if you belong to more than one workspace, which to use — then a key is minted for exactly that workspace. You never paste a credential, and revoking the grant ends access.
Add the URL with a key from your dashboard — the same key the Obsidian plugin uses:
{
"mcpServers": {
"tpsreport": {
"url": "https://tpsreport-mcp-customers-325927718367.us-central1.run.app/mcp",
"headers": { "Authorization": "Bearer hifi_YOUR_KEY" }
}
}
}Start with whoami to confirm which workspace you resolved to, then get_memory_directive to pick up the policy for the session.
It is a Model Context Protocol server that connects any MCP-aware agent to your TPS Report workspace. The agent can search your knowledge base, read exact pages, author and publish new ones, and record what it learned — as ordinary tool calls.
Retrieval is only half of it. The agent also writes back what it learned as a typed, Git-versioned page a human can edit, which is then re-indexed — so the corpus improves between runs instead of staying static.
Your codified knowledge base, not the open web. Queries filter on metadata first, then run vector and keyword search together, fused and reranked, with facets for tags, intents, keywords, report path, and source type.
The workspace memory policy: what agents should watch for and where learnings route. It is a normal page you edit in the editor, and every agent picks up the change on its next session.
Any client that speaks MCP. Claude Desktop and claude.ai connect over OAuth 2.1; Claude Code, Cursor, Cline, Windsurf, and Zed connect with a bearer key in their MCP config.
Yes, including white-labelled ones. There is one endpoint for every workspace, and your credential decides which workspace you reach — a key scopes to where it was minted, and OAuth sign-in asks which workspace to use.
No. Per-tenant deployments are not required. The same endpoint serves every workspace, and cross-workspace choices are validated against your real memberships server-side.
Writes are Git-versioned and optimistic-locked, so a concurrent edit conflicts loudly rather than silently overwriting. Every change stays in version history.
No. It is a hosted connector — add the URL to your client. Even the skills are served over the connector, so nothing is cloned onto your machine.
list_skills shows what your workspace serves and get_skill returns a complete package — instructions, references, and scripts — so the session authors to your standard. For a thinner setup, get_authoring_playbook and validate_folder do the same job server-side.
Prefer to work in your vault? The Obsidian plugin syncs the same workspace bidirectionally, so pages an agent writes here show up in your vault and vice versa. Get the Obsidian plugin →