Optional integration for observability with Datadog LLM Observability, allowing telemetry and monitoring of tool usage with privacy redaction options.
Provides tools for searching, browsing, and retrieving articles from the Wealthsimple Help Center via the public Zendesk Help Center API. Enables full-text search, taxonomy browsing, article retrieval, and URL resolution.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Wealthsimple Help Center MCP search help center for TFSA contribution limit"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Unofficial Model Context Protocol server that wires AI agents into the Wealthsimple Help Center — 7 typed tools for full-text search, taxonomy browsing, and article retrieval. Public Zendesk JSON API only. No scraping. No account credentials. Opt-in observability with privacy redaction.
🪙 Independent, unofficial project. This is a community-built MCP integration. It is not built, endorsed, sponsored, or maintained by Wealthsimple Technologies Inc. or @wealthsimple on GitHub. "Wealthsimple", the help center, and all article content remain the property of Wealthsimple Technologies Inc.; this server only fetches and surfaces what their public, unauthenticated Zendesk Help Center API chooses to return. For account-specific or product support, please contact Wealthsimple directly via their official channels.
The Wealthsimple Help Center is the canonical source of truth for how Wealthsimple's products work — TFSA / RRSP / FHSA mechanics, transfer rules, fees, tax slips, supported countries, options trading, crypto, Cash, Trade, Invest, and more. Wiring an agent into the help center via this MCP server lets it answer Wealthsimple-related questions with cited, up-to-date, structured content rather than memorized snapshots from training data.
This MCP exposes the help center via 7 specialised tools, each with both an inputSchema and an outputSchema so MCP clients receive validated structuredContent alongside the human-readable text. Every Zendesk response is parsed through Zod schemas at the network boundary — tools never see loosely-typed data.
Related MCP server: mcp-server-zendesk
🪙 Cited, up-to-date answers — every article a tool returns includes its public help-center URL, so the agent can ground claims in a real source rather than guessing.
📈 Type-safe end-to-end — TypeScript strict mode + Zod boundary validation. A breaking change in the upstream API surfaces as a parse error, not corrupt agent context.
🏦 No auth, no scraping, no surprise costs — runs entirely on the public, unauthenticated Zendesk Help Center API. Zero rate limits in normal use.
💰 Cache-friendly by default — 30 min TTL + 256-entry LRU cache. The help center mutates slowly; cache hit rates are very high in interactive sessions.
⚡ Resilient client — 15 s request timeouts, up to 2 retries with exponential backoff + jitter on 408 / 425 / 429 / 5xx.
🔒 Opt-in observability with privacy redaction — Datadog LLM Observability built in but off by default. When on, two redaction flags let you keep latency / error / throughput signal without forwarding free-text user queries.
🇨🇦 Bilingual ready — WEALTHSIMPLE_HELP_LOCALE=fr swaps to the French content set.
🧱 Boundary-clean architecture — zendesk.ts is the only file that touches the network; telemetry.ts is the only file that imports dd-trace. Easy to reason about, easy to swap vendors.
Every tool below ships with both inputSchema and outputSchema (Zod-validated). Clients render structuredContent alongside the human-readable text.
Tool | Purpose |
| Full-text search across every published article. Reach for this first. Returns ranked results with title, URL, snippet, labels, section IDs. |
| Hierarchical view of the entire help center: categories → sections → article titles. Big payload — prefer |
Tool | Purpose |
| Top-level taxonomy: Get Started, Move Money, Investing, Spending, File Taxes, Your Profile. |
| Sections inside a category (or all sections). |
| Article summaries inside a single section. |
Tool | Purpose |
| Fetch a single article body by ID. Returns Markdown by default; |
| Resolve a public |
Once connected, try asking your AI assistant:
"Use the wealthsimple-help-center MCP to explain how the FHSA contribution room carryover works. Search the help center for FHSA contribution rules, fetch the most relevant article in full, and cite the public URL in your answer."
Behind the scenes the agent calls search_help_center({ query: "FHSA contribution carryover" }), picks the top result, calls get_article({ article_id: <id>, format: "markdown" }), and grounds the answer in the Markdown body — with the original help.wealthsimple.com URL as the citation.
Node ≥ 20 (uses node --env-file and other modern features)
npm (no other package manager supported in this repo)
git clone https://github.com/tatianathevisionary/wealthsimple-mcp.git
cd wealthsimple-mcp
npm install
npm run build
npm start # runs build/index.js on stdioFor local development with hot reload:
npm run dev # tsx watch src/index.tsType-check only:
npm run typecheck{
printf '%s\n' \
'{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-03-26","capabilities":{},"clientInfo":{"name":"smoke","version":"0.0.0"}}}' \
'{"jsonrpc":"2.0","method":"notifications/initialized"}' \
'{"jsonrpc":"2.0","id":2,"method":"tools/list","params":{}}' \
'{"jsonrpc":"2.0","id":3,"method":"tools/call","params":{"name":"search_help_center","arguments":{"query":"TFSA contribution","limit":2}}}'
sleep 6
} | node build/index.jsYou should see clean JSON-RPC over stdout, all 7 tools listed, and 2 real Wealthsimple TFSA articles returned.
After npm run build, point your MCP client config at the built entry script.
Claude Desktop / Cursor / VS Code (mcp.json):
{
"mcpServers": {
"wealthsimple-help-center": {
"command": "node",
"args": ["/absolute/path/to/wealthsimple-mcp/build/index.js"]
}
}
}Claude Code:
claude mcp add wealthsimple-help-center -- node /absolute/path/to/wealthsimple-mcp/build/index.jsAll configuration is via environment variables. Sensible defaults are provided.
Env var | Default | Description |
|
| Base URL for the Zendesk Help Center API. |
|
| Locale for category / section / article queries. Set to |
|
| User-Agent header sent to the help center. Identifies traffic as this project (not Wealthsimple itself). |
|
| Per-request timeout in ms. |
|
| Response cache TTL in ms. |
Telemetry is off by default and adds zero overhead unless explicitly enabled — dd-trace is bundled but lazy-loaded. Set either DD_API_KEY (for agentless) or WEALTHSIMPLE_HELP_TELEMETRY_ENABLED=true (when you have a local Datadog Agent) to turn it on.
🚨 Read Privacy & data tracking before turning telemetry on. When LLM Observability is enabled, this MCP captures tool inputs (including free-text search queries) and outputs and ships them to Datadog. The default (off) sends nothing. Two opt-in redaction flags (
WEALTHSIMPLE_HELP_TELEMETRY_REDACT_IO,WEALTHSIMPLE_HELP_TELEMETRY_REDACT_URLS) let you keep telemetry on without forwarding content.
Env var | Default | Description |
| (unset) | Set to |
| (unset) | If set, telemetry initializes automatically (typical for agentless mode). |
|
| Datadog site, e.g. |
|
| Service name shown in Datadog. |
| (unset) | Environment tag, e.g. |
| server version | Version tag for deployments. |
|
| Set to |
|
| Set to |
|
| Logical app name in LLM Obs. Setting this implicitly enables LLM Obs. |
|
| Send LLM Obs spans directly to Datadog (no local Agent). Requires |
|
| Skip annotating |
|
| Strip query strings from the |
Copy .env.example to .env, fill in DD_API_KEY, then:
npm run start:telemetry # node --env-file=.env build/index.js
npm run dev:telemetry # tsx watch --env-file=.env src/index.ts.env is gitignored. Do not commit it.
When adding this server to a Claude Desktop / Cursor / similar MCP config, pass the env vars in the env block:
{
"mcpServers": {
"wealthsimple-help-center": {
"command": "node",
"args": ["/absolute/path/to/wealthsimple-mcp/build/index.js"],
"env": {
"DD_API_KEY": "...",
"DD_SITE": "us5.datadoghq.com",
"DD_LLMOBS_ENABLED": "true",
"DD_LLMOBS_AGENTLESS_ENABLED": "true",
"DD_LLMOBS_ML_APP": "wealthsimple-help-center-mcp"
}
}
}
}When telemetry is on (and only then), this server sends data over the network to Datadog. Be deliberate about enabling it — what follows is the full inventory of what gets shipped, what does not, and how to redact further.
Per tool call — tool name (e.g. search_help_center), latency, success/error status. With DD_LLMOBS_ENABLED=true, also:
inputData — the full arguments the upstream agent passed in. For most tools (list_categories, list_sections, get_article, browse_taxonomy) this is just numeric/string IDs and is low-risk. For search_help_center it includes the free-text query string, which agents typically forward verbatim from a user prompt. If your user types personal information into their agent — name, email, account number, government IDs, financial details — it can end up in this field.
outputData — the tool's response. Help Center articles are public content authored by Wealthsimple, so no Wealthsimple user PII flows out this way; the worst case is a verbose article body.
Per outbound Zendesk request — full URL (including the search-term query string), HTTP status, retry count, latency.
dd-trace defaults — Node runtime metrics (CPU, RSS memory, GC, event-loop), process info (pid, hostname), error stack traces (which include local file paths from your machine).
Any Wealthsimple account data — balances, holdings, transactions, KYC info, session tokens, identity documents. This server only talks to the public, unauthenticated help center API. It has no path to user-account endpoints; Wealthsimple PII is structurally out of reach.
Your DD_API_KEY — used by dd-trace for transport, never logged or serialized into spans.
The contents of .env as a file — only the env vars dd-trace and this module explicitly read are used.
Anything from other processes on your machine — telemetry instrumentation is scoped to this server's own code.
To the Datadog regional intake set in DD_SITE (e.g. us5.datadoghq.com). It is then governed by your Datadog data retention and privacy settings. Data does not flow to Wealthsimple, to this project's maintainers, or to any other third party. Wealthsimple has no visibility into your telemetry — it's a separate channel.
Knob | Effect |
Leave telemetry off (default) | Nothing sent anywhere. |
| Tool spans still emit (latency, error counts, throughput preserved) but |
| Strips query strings from the |
| Native |
| Stop emitting Node runtime metrics. Useful if you want zero machine fingerprinting. |
Solo / personal use where you control every query → enabling telemetry with full IO capture is fine and gives the best signal.
Shared device, team, or anyone-but-you typing the queries → set WEALTHSIMPLE_HELP_TELEMETRY_REDACT_IO=true and WEALTHSIMPLE_HELP_TELEMETRY_REDACT_URLS=true. You still get latency, error rates, and throughput; you do not ship user content.
Production / customer-facing deployment → keep telemetry off, or run with both redaction flags plus a privacy review of dd-trace's default capture set against your DPA / privacy policy. This project's authors have not done a formal DPIA — that is on the operator.
This server does not, and is structurally unable to, send the Wealthsimple Help Center any of its telemetry data — telemetry is a separate channel to Datadog only.
This project sits on top of work done by others — credit where due:
Wealthsimple Technologies Inc. (@wealthsimple) — for publishing a comprehensive, well-organised help center and exposing it through a stable, public Zendesk JSON API. Every article this server returns is authored and maintained by their team. This project is grateful for their open, well-documented public API and would not exist without it.
Anthropic and the broader Model Context Protocol community — for the protocol spec and the @modelcontextprotocol/sdk TypeScript SDK that this server is built on.
Zendesk — for the Help Center platform whose public API this server consumes.
Datadog — for the dd-trace Node SDK and the LLM Observability product used for optional telemetry.
Colin McDonnell — for Zod, used at every Zendesk response boundary for runtime validation.
damionrashford/RivalSearchMCP — for the README structure inspiration (badges row, FAQ, "give it a star" pattern). A solid example of a community-built MCP server presenting itself professionally.
No. This server only talks to the public, unauthenticated Zendesk Help Center API. No Wealthsimple credentials, no OAuth, no session — there's literally no code path here that touches Wealthsimple-account data.
No, not for the MCP itself. The Zendesk Help Center API is unauthenticated. The only API key that matters is optional: DD_API_KEY if you want to enable Datadog telemetry. Without it, the server runs as a pure local process and dd-trace is never even loaded.
No. This is an independent, community-built integration. It is not built, sponsored, endorsed, or maintained by Wealthsimple Technologies Inc. or @wealthsimple. For account-specific or product support, contact Wealthsimple directly via their official help portal.
Structurally no. This MCP only fetches public help center articles. There is no code path here that can read account balances, transactions, KYC info, session tokens, or any other Wealthsimple-side personal data — the upstream API doesn't expose it and this project doesn't authenticate. The only PII risk is if your prompts to the agent include personal information that the agent then forwards verbatim into a search_help_center.query. The Privacy section above explains how to redact even that.
help.wealthsimple.com?No. The server uses the public Zendesk Help Center JSON API exclusively. No HTML parsing of /hc/... pages, no headless browser, no anti-bot circumvention. If a feature requires data the Zendesk API doesn't expose, the answer will be "we won't add it" rather than "let's scrape."
Any MCP-compatible client. Tested locally with Claude Desktop, Cursor, Claude Code, and VS Code MCP via stdio transport. See Wire into an MCP host for config snippets.
Because the Zendesk API's response shapes occasionally change a field, and an agent corrupting on a silent shape drift is a much worse failure mode than a parse error at the boundary. Zod's safeParse at every response converts upstream surprises into typed errors that surface in stderr instead of malformed structuredContent poisoning a tool result. The TypeScript-strict + Zod combination is doing real work, not aesthetic work.
Yes. MIT-licensed; clone freely. Set WEALTHSIMPLE_HELP_LOCALE=fr to switch to the French content set (the help center is bilingual). All other env vars are documented above.
See CONTRIBUTING.md for the dev setup, architectural rules, labelling system, and PR conventions. TL;DR: open an issue first, work on a branch, PR with Closes #N.
Bug in this MCP server (schema drift, broken tool, missing feature) → open an issue on this repo.
Problem with the content of a help center article (accuracy, product behavior, "is this still true") → contact Wealthsimple support via their official help portal. This project does not author or modify article text.
MIT License © contributors. Article content fetched from the Wealthsimple Help Center is © Wealthsimple Technologies Inc. and is not covered by this license — it is surfaced via their public API for use by tools that consume this server, never redistributed or bundled.
"Wealthsimple" is a registered trademark of Wealthsimple Technologies Inc. All references in this repository are descriptive and nominative — used solely to indicate that this MCP server interfaces with Wealthsimple's public help center API. No affiliation, sponsorship, or endorsement by Wealthsimple Technologies Inc. is claimed or implied. "Datadog", "Zendesk", "Anthropic", and "Model Context Protocol" are trademarks of their respective owners.
If you find this MCP useful — for grounding agent answers in Wealthsimple's actual help center, for studying how to build a typed MCP server, for learning what opt-in privacy-aware telemetry looks like — please consider giving it a star. It helps others discover the project and motivates continued maintenance.
Return a hierarchical map of the entire help center: every category → its sections → its article titles and IDs (no bodies). Use this to give an agent a holistic picture of what the help center covers, as a precursor to targeted retrieval. Result can be large (~hundreds of articles) — prefer search_help_center for narrow queries.
| Name | Required | Description | Default |
|---|---|---|---|
| include_articles | No | If true (default), include article titles under each section. If false, return only categories→sections. | |
| articles_per_section | No | Cap on articles per section (default 50). |
| Name | Required | Description |
|---|---|---|
| category_count | Yes | |
| section_count | Yes | |
| article_count | Yes | |
| categories | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that the result can be large (~hundreds of articles) and that no article bodies are included, which is sufficient for behavioral expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences plus parameter info; front-loaded with main purpose, no wasted words. Highly efficient and structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given output schema exists, description explains return structure (categories→sections→articles) and size warning. Complete for understanding the tool's output and usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. The description adds default values and effect of include_articles, but does not provide significant additional meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description specifies returning a hierarchical map of the entire help center with categories, sections, article titles, and IDs, and distinguishes from sibling tools like search_help_center for narrow queries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: to get a holistic picture as a precursor, and when not: for narrow queries prefer search_help_center. Provides clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch the full content of one article. By default returns a clean Markdown rendering of the article body (HTML stripped, links and headings preserved). Pass format: "html" for the raw HTML if needed.
| Name | Required | Description | Default |
|---|---|---|---|
| article_id | Yes | Numeric article ID. Obtain via search_help_center or list_articles. | |
| format | No | Body rendering. Default `markdown`. |
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| title | Yes | |
| url | Yes | |
| section_id | Yes | |
| locale | Yes | |
| labels | Yes | |
| updated_at | Yes | |
| format | Yes | |
| body | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It explains the default output format and alternatives, including that HTML is stripped. For a read-only fetch tool, this is adequate. It does not discuss error handling or authentication, but these are not critical for a simple fetch.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loading the main purpose in the first sentence. Every sentence provides essential information without redundancy. It is efficiently structured for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 parameters, 1 required, output schema provided), the description is complete. It explains default behavior, format options, and how to get the article_id. No additional context is necessary for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. The description adds value beyond schema by specifying how to obtain article_id ('via search_help_center or list_articles') and explicitly stating the default format. This helps an agent understand parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Fetch the full content of one article,' which is a specific verb-resource combination. It is distinct from sibling tools that browse taxonomy, list articles/categories/sections, resolve URLs, or search. The mention of 'clean Markdown rendering' and format options further clarifies the exact output.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear guidance on format usage: default Markdown vs. raw HTML or text. It implies the tool is used after obtaining an article_id via search_help_center or list_articles. However, it does not explicitly state when not to use it or exclusions; the context of sibling tools helps, but direct exclusion is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return article summaries (no body) inside a single section. Use after list_sections to discover specific articles, then call get_article for full content.
| Name | Required | Description | Default |
|---|---|---|---|
| section_id | Yes | Section ID returned by list_sections. | |
| limit | No | Max number of articles (default 50, hard cap 200). |
| Name | Required | Description |
|---|---|---|
| section_id | Yes | |
| count | Yes | |
| articles | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool returns only summaries and no body content, which is a key behavioral trait. It implies a read-only operation, which is consistent with no annotations provided. Additional details like ordering or pagination could further improve transparency, but the current disclosure is strong.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two efficient sentences, each serving a distinct purpose: stating the tool's output and providing workflow context. No redundant or extraneous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (context signal), the description appropriately focuses on usage context and scope. It explains the relationship to sibling tools and the intended workflow, making it complete for an agent to use effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters fully described in the schema. The description does not add new semantic information beyond the schema, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns article summaries without the body, and it specifies the scope as 'inside a single section'. It also distinguishes itself from siblings by referencing `list_sections` and `get_article` in the workflow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells the agent to 'Use after list_sections to discover specific articles, then call get_article for full content'. This provides clear when-to-use and next-step guidance, differentiating it from sibling tools like `browse_taxonomy` and `search_help_center`.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the top-level categories (Get Started, Move Money, Investing, Spending, File Taxes, Your Profile) of the Wealthsimple Help Center. Useful as the entry point for taxonomy-driven exploration before drilling into sections and articles.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| count | Yes | |
| categories | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description discloses that this is a read operation returning top-level categories. It names specific categories, giving transparency about return values. No behavioral surprises.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two succinct sentences, front-loaded with action and intent. Every word adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no parameters and an output schema present, the description is complete. It explains the tool's purpose, typical usage context, and return content. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters; schema coverage is 100% trivially. Description adds no extra parameter info, but with zero parameters, baseline is 4. No need for elaboration.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists top-level categories of the Wealthsimple Help Center, naming specific examples. It effectively distinguishes from sibling tools like list_sections which drill deeper.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
States it is useful as an entry point for taxonomy-driven exploration before drilling into sections and articles, implying when to use it. Does not explicitly mention alternatives or when not to use, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List sections, optionally filtered to one category. Sections group related articles (e.g. "TFSA", "Crypto deposits"). Pass a category_id from list_categories to scope.
| Name | Required | Description | Default |
|---|---|---|---|
| category_id | No | If provided, only return sections inside this category. Obtain via list_categories. |
| Name | Required | Description |
|---|---|---|
| count | Yes | |
| sections | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description bears full responsibility for behavioral disclosure. It only mentions optional filtering and the nature of sections, but omits details like pagination, rate limits, or what happens when no sections match.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no wasted words. The main action is front-loaded ('List sections'), followed by a clear optional filter and examples.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and sibling tools, the description covers the essential aspects: what sections are, the optional filter, and a reference to list_categories. Minor gap: no mention of sorting or response format, but adequate for a simple list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the description adds value by telling agents to obtain category_id via list_categories and giving examples of section names, which aids correct parameter use beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists sections and explains they group related articles, with examples like 'TFSA' and 'Crypto deposits'. It distinguishes itself from siblings by mentioning the optional category_id filter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises passing a category_id from list_categories to scope results, implying a usage sequence. However, it does not explicitly state when not to use this tool or provide direct comparisons with siblings like list_articles or search_help_center.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Given a public help.wealthsimple.com article URL (e.g. https://help.wealthsimple.com/hc/en-ca/articles/4404053510299-Open-a-TFSA), fetch and return the full article. Useful for following citations or links the user has pasted.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | A help.wealthsimple.com article URL. | |
| format | No |
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| title | Yes | |
| url | Yes | |
| format | Yes | |
| body | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description lacks behavioral details such as error handling, rate limits, or authentication requirements. Only the basic fetch-and-return behavior is stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loading the core function with an example, and adds a use case. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 2 parameters (1 optional), an output schema, and no annotations, the description covers the essential purpose but omits behavioral details and parameter semantics, making it minimally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% (only url described). The description does not explain the format parameter (markdown/html/text) beyond the schema enum, missing an opportunity to clarify usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches and returns full articles from a given help URL, with an example URL. It distinguishes from siblings like get_article by focusing on URL resolution.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It says 'Useful for following citations or links the user has pasted,' providing clear usage context. However, it does not explicitly mention when not to use or compare with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full-text search across every public Wealthsimple Help Center article. Returns a ranked list of articles with titles, URLs, snippets, labels, and section IDs. Use this whenever the user asks anything about Wealthsimple products (Trade, Invest, Cash, Crypto, Tax, registered accounts like TFSA / RRSP / FHSA, transfers, deposits, etc.) — the help center is the canonical source of truth.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Free-text search query, e.g. "TFSA contribution limit", "options trading fees". | |
| limit | No | Max results to return (default 10, hard cap 50). |
| Name | Required | Description |
|---|---|---|
| query | Yes | |
| count | Yes | |
| results | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description clearly states it is a read-only search operation that returns existing public content. It does not mention side effects, but the behavior is well-defined as a search-and-respond tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first describes functionality and output, second provides usage guidance with examples. No filler, front-loaded, every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists (not shown), so return values are already defined. Description mentions returned fields (titles, URLs, snippets, labels, section IDs). Given sibling tools and full parameter documentation, the description is complete for a search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers both parameters fully (100% coverage). Description adds value with concrete examples (e.g., 'TFSA contribution limit') and confirms default/max limit behavior, going beyond schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Explicitly states it performs full-text search across public Wealthsimple Help Center articles and returns rankings with specific fields (titles, URLs, snippets, labels, section IDs). This clearly distinguishes it from sibling tools like browse_taxonomy or get_article.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: 'Use this whenever the user asks anything about Wealthsimple products...the help center is the canonical source of truth.' Does not explicitly exclude alternatives, but the context is clear and helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0browse_taxonomyget_articlelist_articleslist_categorieslist_sectionsresolve_help_urlsearch_help_centerScored across 7 tools
Each tool has a clearly distinct role: browsing taxonomy, listing categories/sections/articles, retrieving full content by ID or URL, and searching. No overlapping purposes.
All tool names consistently follow a verb_noun pattern (browse_taxonomy, get_article, list_articles, etc.) with predictable naming.
Seven tools cover the full scope of help center exploration (structure, search, retrieval) without being excessive or sparse.
The set includes hierarchical browsing, targeted listing, full-text search, and article retrieval by ID or URL, leaving no obvious gaps for typical help center queries.
Gateway between LLM agents and world data through eight tools and a bundled endpoint catalog.
Persistent memory and knowledge management for AI agents with semantic search and 50+ tools.
Connect AI tools to Weav customer service. Search conversations, reply, and manage knowledge.
Team knowledge base for snippets, API calls and docs. Agents search and file items; humans review.
