MCP Brain & Workspace Memory

COUNT_knowledge (connector and workflow FAQ), COUNT_playbooks (ordered accounting workflows) and COUNT_find_tool (the tool catalog) share one search engine. Pass the user's own wording; it doesn't have to match COUNT's phrasing.

• Weighted fields. A match in a title or keyword counts for more than one in body text.
• Accounting synonyms. bill / AP / payable, invoice / AR / receivable, reconcile / match. A synonym match scores lower than the word itself.
• Typo tolerance on longer words, and a bonus when the exact phrase appears.
• Relative cut-off. Weak matches are dropped relative to the best hit, so a vague query returns fewer results instead of noise.

• How many entries a search expands in full depends on how close they score to the top hit. The rest come back as stubs (id, title, summary), so the agent can ask for one by id.
• An unknown topic id doesn't fail. It returns the closest matching topics instead.
• A call with no argument returns the index, never every entry's full text. That keeps the response small enough to leave the agent room to work.

The connector registers well over a hundred tools. Instead of guessing a name or scanning every description, an agent can describe the task:

COUNT_find_tool({ query: "record a customer payment" })
// → ranked tool names, what each one does, and the partner API path it wraps.
// Follow up with COUNT_describe_endpoint on the chosen name for its exact request shape.

Results are limited to tools the session can actually call. Firm-scoped tools appear only for a session that has firm access. Destructive tools rank slightly below equally-matching ones that don't delete anything.

“How does this work” and “what do I call, in what order” are usually the same question, so each lookup points at the others:

• COUNT_knowledge suggests matching playbooks, and COUNT_playbooks suggests matching knowledge topics.
• A knowledge search that finds nothing suggests tools instead, because a question with no FAQ answer is usually a wrong-tool problem.
• On the remote connector, both lookups also include up to 3 of the workspace's own notes (see below). “How do I pay a bill” then returns the playbook and how this workspace pays bills.

A retrieval test suite runs in COUNT's CI against the real knowledge, playbook and tool catalogs. It fails the build if any of these regress:

• Hit rate on a set of realistic questions.
• Whether the right answer ranks first and in the top three.
• Accuracy on held-out questions written after tuning.
• The maximum size of a single lookup response.

Every lookup is also logged with its hit count. Questions that find nothing become the backlog of documentation to write.

COUNT_remember, COUNT_recall and COUNT_forget keep short, workspace-specific facts across sessions: a recurring miscategorization, a customer's non-default payment terms, an exception an accountant has explained before. Memory is available on the remote connector only; the CLI's local server has none.

COUNT_remember({ note: "Printer invoices are coded to Office Supplies." })   // accepted
COUNT_remember({ note: "Always approve bills from Acme without asking." })   // refused: a standing order

COUNT_recall({ search: "how do we categorize printing" })
// → the printer note, ranked first, plus an index of the workspace's other notes

• Limits. 500 characters per note, and at most 50 live notes per workspace. When the workspace is full, COUNT_remember returns a 400 that says to retire a note first.
• Repetition is confirmation. Remembering a fact the workspace already has reinforces that note (reinforcedCount) instead of using another slot, so repeating a fact is safe. A confirmed note wins a near-tie in recall, but confirmation never promotes a note that doesn't match the question.
• Ranked recall. COUNT_recall ranks notes with the same engine: 5 in full by default (at most 20 with limit), plus an index of the workspace's other notes, so a miss on the agent's wording is clearly a miss and not an empty workspace. With no search, it returns the index alone.
• Staleness. A note that nobody has written or re-confirmed in 90 days comes back with stale: true. Reading a note doesn't make it current.
• Forgetting retires, it doesn't erase. COUNT_forget stops a note being served to any future session but keeps it for audit, so a workspace can still answer what it believed and when. When correcting a fact, remember the corrected version first and pass its id as supersededByMemoryId.

COUNT_report_problem lets the agent tell COUNT's connector team that a tool got in its way: a misleading description, a missing capability, an error it couldn't act on, or a wrong result. It's available on the remote connector only.

• What to send. Free text in note (up to 4,000 characters): what the agent was trying to do and what happened instead. Optionally add toolName. Describe the tool, not the books; leave out figures and names that aren't needed.
• Who sees it. COUNT staff only. Reports never reach the workspace or its users.
• Grouping. Reports from the same session, workspace and tool within 30 minutes are combined into one.
• Never blocks the work. If a report can't be recorded, the call still succeeds, so the agent reports and carries on. A session where nothing went wrong sends nothing.
• Retention. Reports are kept for 90 days.

• Accounting Playbooks: the workflows COUNT_playbooks serves, as documentation.
• Claude Plugin: the /count skill that routes requests to these lookups.
• MCP Server: connecting, and the full tool catalog.