This server provides read-only, local bundled documentation search and retrieval for Bharosa integration planning.
List, search, and read public Bharosa documentation guides and references.
Search API reference documents and read canonical API operation details, including method, path, parameters, body/responses, schema document IDs, and examples; method filters are documentation-only.
Search SDK, cURL, and guide code examples, then read allowlisted examples with pagination, source hashes, and validation scope.
Return pinned snapshot/source provenance and deterministic literal search results.
Cannot access accounts, execute API requests or code, transfer assets, use credentials, fetch remote resources, or accept arbitrary filesystem paths.
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., "@bharosa-docs-mcp find the create contract API operation and show a TypeScript SDK example"
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.
Bharosa helps coding assistants plan and build integrations using an integration skill and seven read-only documentation tools. It cannot access accounts, execute API requests, transfer assets, or run examples.
Version 0.3.2 bundles the public website v29 documentation and public bharosa@0.6.0 contracts: 113 documents, 32 API operations and 126 examples. The source checkpoint is signed commit 1e1b73a6b4cee0fb0b8e8d9c5a4bb04f5c68fcf4. This GitHub full-plugin release is separate from npm server publication and public directory acceptance.
The hosted service is https://mcp.bharosa.finance/; /up is its health check and /mcp is retired. The service serves a pinned documentation snapshot. Check tool response provenance when comparing it with the website.
Related MCP server: @prosodyai/mcp-docs
Extract the full-plugin release archive and run from its root:
codex plugin marketplace add .
codex plugin add bharosa-docs@bharosaFor Claude Code, use a session-only full plugin:
claude --plugin-dir ./plugins/bharosa-docsOr install its local catalogue persistently:
claude plugin marketplace add .
claude plugin install bharosa-docs@bharosaStart a new session. Ask: “Use the Bharosa integration skill to plan an own-account portfolio dashboard. Retrieve the relevant guides and examples, state their versions, and propose synthetic tests. Do not use real credentials.” In Claude Code the explicit skill is /bharosa-docs:bharosa-integration.
These install the skill and MCP connection together. A bare MCP connection does not install the skill. Codex desktop UI installation and Claude web skill loading are not proven by CLI tests. Your AI host needs its own login and usage allowance; the public documentation MCP needs no Bharosa login or key. No public directory approval is required for the local catalogue route.
bharosa_docs_list, bharosa_docs_search, bharosa_docs_read
bharosa_api_search, bharosa_api_details
bharosa_examples_search, bharosa_examples_read
All responses carry snapshot/source provenance. Search is literal and deterministic. Use returned IDs and pagination; reads are capped at 8,000 UTF-16 code units, with a universal serialized result cap of 131,072 bytes. API method filters select reference text, never an action. The integration skill provides grounded planning; there is no autonomous planner or account-action tool.
Use Node.js 22.12 or later on a supported LTS line. Install the reviewed tarball in an isolated project, then run its CLI directly:
npm install --ignore-scripts /absolute/path/bharosa-docs-mcp-0.3.2.tgz
node node_modules/bharosa-docs-mcp/dist/cli.js --check
node node_modules/bharosa-docs-mcp/dist/cli.js --stdioNo credentials, remote fetch or arbitrary filesystem paths are accepted by tools. Keep stdout reserved for MCP protocol messages.
Source organization: src/ runtime; scripts/ pinned generators/build/package verification; tests/ synthetic protocol/security/example checks; assets/ generated public corpus; plugins/ host manifests and skill. Runtime dependencies are bundled for offline installation. The development lock pins the verified public SDK archive and registry integrity. Source development requires the pinned public dependencies; clean archive consumption is separately tested.
npm run build
npm test
npm run verify:package
BHAROSA_MARKETING_ROOT=/path/to/reviewed/staged/public/input npm run docs:check
BHAROSA_MARKETING_ROOT=/path/to/reviewed/staged/public/input npm run coding:checkGenerators accept only pinned public source files. Website modules retain marketing source paths; separately staged public SDK contracts retain their original sdk/test/ paths and hashes. No private first-party contracts or licensed UI assets are included. Changing a source requires a reviewed checkpoint, regeneration, tests and a new release; installed snapshots do not refresh themselves.
The analytics reference includes the reviewed production metadata correction. Synthetic checks are not proof of an authenticated production journey. Determine delegated onboarding availability from the coordinated deployment evidence; this local candidate does not establish live availability. Do not invent OAuth endpoints or grant credentials.
MIT, with dependency notices in THIRD-PARTY-NOTICES.txt. Report issues at https://github.com/bhafin/plugin/issues using synthetic examples only. Never post credentials, financial records or private logs. Public docs: https://developers.bharosa.finance/docs/documentation-assistant#hosted . Directory listings remain pending.
Read one canonical API operation: method, path, parameters, body/responses and available source examples. Follow schema document IDs for referenced definitions. No API execution or credentials.
| Name | Required | Description | Default |
|---|---|---|---|
| operationId | Yes |
| Name | Required | Description |
|---|---|---|
| notice | Yes | |
| operation | Yes | |
| exampleIds | Yes | |
| reviewedOn | Yes | |
| sdkVersion | Yes | |
| availability | Yes | |
| codingSha256 | Yes | |
| bundleVersion | Yes | |
| codingVersion | Yes | |
| checkpointDate | Yes | |
| contractVersion | Yes | |
| schemaDocumentIds | Yes | |
| contractSourcePath | Yes | |
| contractSourceSha256 | Yes | |
| publicContractSha256 | Yes | |
| publicContractVersion | Yes | |
| approvedManifestSha256 | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so safety is covered. The description adds genuinely new context: what the response contains, that it resolves referenced definitions via schema document IDs, and that no execution or credentials are involved.
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?
Three compact sentences, front-loaded with the primary action, then the chaining hint, then the boundary statement. No filler.
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 so return values need not be spelled out, and the description still sketches them; chaining guidance and the no-execution boundary round it out. The missing piece is how to source the operationId.
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?
Only one parameter with 0% schema description coverage; the schema constrains its format (pattern, max length) but not its meaning. The description implies operationId identifies the operation but never says how to obtain one (presumably from bharosa_api_search), leaving the main practical gap.
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?
States a specific verb ('Read') and resource ('one canonical API operation') and enumerates the payload: method, path, parameters, body/responses, examples. It implicitly distinguishes itself from the search/list siblings by returning full detail for a single operation, though it never names them.
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?
'No API execution or credentials' scopes it as documentation-only, and 'Follow schema document IDs for referenced definitions' hints at chaining to a docs-read tool. But there is no explicit when-to-use-this-vs-bharosa_api_search or where to obtain an operationId.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search bundled API reference documents. Every result is documentation text, including references describing write endpoints. The optional method filter matches a documented HTTP verb; it does not send a request or select an action to execute. This tool only reads a local index and can never read or write an account.
| Name | Required | Description | Default |
|---|---|---|---|
| group | No | ||
| limit | No | ||
| query | Yes | Required nonblank literal search text, even when using group or method filters. For monthly API references, try query nav with group monthly. Maximum 120 raw characters. | |
| method | No | Filter reference documents by their documented HTTP verb. Never executes that method or any network request. |
| Name | Required | Description |
|---|---|---|
| total | Yes | |
| notice | Yes | |
| matches | Yes | |
| reviewedOn | Yes | |
| sdkVersion | Yes | |
| availability | Yes | |
| codingSha256 | Yes | |
| bundleVersion | Yes | |
| codingVersion | Yes | |
| checkpointDate | Yes | |
| contractVersion | Yes | |
| contractSourcePath | Yes | |
| contractSourceSha256 | Yes | |
| publicContractSha256 | Yes | |
| publicContractVersion | Yes | |
| approvedManifestSha256 | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=false, idempotentHint=true, and destructiveHint=false, so the repeated claims that it 'only reads a local index' and 'can never read or write an account' largely restate structured data. The one genuinely additive point is that results are documentation text even for write endpoints, and that the method filter is a metadata match rather than an action — useful disambiguation beyond the annotations, though delivered redundantly.
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 purpose is front-loaded in a single clear sentence, but two of the three sentences are safety disclaimers that overlap each other and duplicate the annotations. The space would have been better spent on sibling differentiation or explaining the group filter.
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 an output schema present, return values need not be explained, and the read-only nature is fully covered. The remaining gap is guidance on the group parameter and on how this differs from sibling search tools, but for a simple 4-parameter read-only search the description is close to sufficient.
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 50%, with the query and method parameters documented in-schema. The description reinforces method as a documented-verb filter that never executes a request, which is meaningful disambiguation, but it says nothing about the group enum (resource/monthly) or the limit bounds, leaving half the parameters unaddressed.
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 first sentence gives a specific verb and resource: 'Search bundled API reference documents.' That is clear and unambiguous, but it never differentiates this tool from close siblings such as bharosa_docs_search or bharosa_api_details, which an agent must distinguish before choosing.
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?
There is no statement of when to use this tool versus the five sibling search/detail tools. The description only clarifies what the tool does not do (execute methods); it offers no routing guidance for choosing between bharosa_api_search, bharosa_docs_search, or bharosa_api_details.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List bundled public documentation. Offset is a document index; at most 20 results. No filesystem or network access from arguments.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| offset | No |
| Name | Required | Description |
|---|---|---|
| total | Yes | |
| notice | Yes | |
| documents | Yes | |
| nextOffset | Yes | |
| reviewedOn | Yes | |
| availability | Yes | |
| bundleVersion | Yes | |
| checkpointDate | Yes | |
| contractVersion | Yes | |
| contractSourcePath | Yes | |
| contractSourceSha256 | Yes | |
| publicContractSha256 | Yes | |
| publicContractVersion | Yes | |
| approvedManifestSha256 | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish that this is a read-only, idempotent, non-destructive, closed-world operation. The description adds useful behavioral context beyond that by noting the 20-result cap and that arguments do not grant filesystem or network access.
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 three short sentences with the purpose front-loaded. Each sentence adds useful information without repetition or filler.
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?
For a simple two-parameter read-only list tool with annotations and an output schema, the description is mostly complete. The main remaining gap is that limit semantics and sibling routing are not spelled out.
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 0%, so the description must carry more weight. It explains offset as a document index and notes a 20-result maximum, but it does not explain the limit parameter's meaning or default, leaving part of the parameter semantics unaddressed.
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 states a clear verb and resource: list bundled public documentation. It is distinguishable from the search/read siblings by the word 'List,' but it does not explicitly name or compare itself to those alternatives.
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?
Usage is implied: use this tool to browse bundled documentation. However, there is no explicit guidance on when to prefer it over bharosa_docs_search or bharosa_docs_read, and no exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read bundled documentation by its allowlisted ID from bharosa_docs_list. Offset and maxChars count UTF-16 code units; at most 8000 per response. No path or URL input.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| offset | No | ||
| maxChars | No |
| Name | Required | Description |
|---|---|---|
| notice | Yes | |
| offset | Yes | |
| content | Yes | |
| document | Yes | |
| nextOffset | Yes | |
| reviewedOn | Yes | |
| availability | Yes | |
| bundleVersion | Yes | |
| checkpointDate | Yes | |
| contractVersion | Yes | |
| contractSourcePath | Yes | |
| contractSourceSha256 | Yes | |
| publicContractSha256 | Yes | |
| publicContractVersion | Yes | |
| approvedManifestSha256 | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety (readOnlyHint, idempotentHint, openWorldHint=false, destructiveHint=false), so the bar is lower. The description adds real behavioral context beyond them: paging is in UTF-16 code units and a single response is capped at 8000, which tells the agent to expect chunked reads and loop. It does not say how truncation/continuation is signalled, which is the one remaining behavioral gap.
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?
Three compact sentences, front-loaded with the core action and prerequisite, then the unit/size caveat, then the negative constraint. Every clause adds information the agent does not already have from structured fields.
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?
An output schema exists, so return values need not be explained, and annotations cover the safety profile. For a paginated read tool the only substantive omission is guidance on detecting truncation and advancing offset, but the unit and cap statements make correct paging largely inferable.
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 0%, so the description must carry the load, and it does for the two ambiguous params: offset and maxChars are declared to count UTF-16 code units with an 8000 ceiling. The id param's meaning is conveyed by "allowlisted ID from bharosa_docs_list" rather than the schema's regex pattern. Missing are defaults and failure behavior for a non-allowlisted ID.
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?
States a specific verb and resource ("Read bundled documentation") and pins the access key to an allowlisted ID sourced from bharosa_docs_list, which cleanly separates it from the search-style siblings. An agent can tell this is ID-based retrieval, not search, without opening any schema.
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 directs the agent to bharosa_docs_list to obtain a valid ID and closes off a likely wrong usage ("No path or URL input"). It stops short of naming bharosa_docs_search as the alternative for when the agent has a query rather than an ID, so the routing is clear but not fully enumerated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search bundled IDs, titles and text using case-insensitive literal AND terms, ranked by exact ID/title and title matches with source-order ties. At most 120 query characters and 20 results; no regex or remote search.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes |
| Name | Required | Description |
|---|---|---|
| total | Yes | |
| notice | Yes | |
| matches | Yes | |
| reviewedOn | Yes | |
| availability | Yes | |
| bundleVersion | Yes | |
| checkpointDate | Yes | |
| contractVersion | Yes | |
| contractSourcePath | Yes | |
| contractSourceSha256 | Yes | |
| publicContractSha256 | Yes | |
| publicContractVersion | Yes | |
| approvedManifestSha256 | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish that the operation is read-only, idempotent, local, and non-destructive. Beyond that, the description discloses matching behavior (case-insensitive literal AND terms), ranking rules (exact ID/title and title matches with source-order ties), and operational limits (120 query characters, 20 results, no regex or remote search).
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 dense sentences with no wasted text, and it front-loads the core action before adding matching, ranking, and limit details. Every clause contributes operational value.
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?
An output schema exists, so return value details are not required in the description. The description covers the search mechanism and constraints sufficiently for invocation, though it could more explicitly clarify the relationship to sibling read/list/search tools.
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 0%, so the description must carry parameter meaning. It explains the query semantics and maximum query length well, and mentions the 20-result cap, but it does not explain the adjustable limit parameter or its default of 5.
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 uses a specific verb and resource: search bundled documentation IDs, titles, and text. It is clear what is searched, though it does not explicitly distinguish this from sibling searches such as bharosa_api_search or bharosa_examples_search.
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 implies usage for literal term searches and rules out regex or remote search, which is useful constraint information. However, it does not say when to choose this over bharosa_docs_list, bharosa_docs_read, or the other search tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a canonical example by allowlisted ID, its optional initialization context and source hash. UTF-16 offsets; at most 8000 code units. Returns text only; never executes code.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| offset | No | ||
| maxChars | No |
| Name | Required | Description |
|---|---|---|
| code | Yes | |
| setup | Yes | |
| notice | Yes | |
| offset | Yes | |
| example | Yes | |
| nextOffset | Yes | |
| reviewedOn | Yes | |
| sdkVersion | Yes | |
| availability | Yes | |
| codingSha256 | Yes | |
| bundleVersion | Yes | |
| codingVersion | Yes | |
| checkpointDate | Yes | |
| contractVersion | Yes | |
| contractSourcePath | Yes | |
| contractSourceSha256 | Yes | |
| publicContractSha256 | Yes | |
| publicContractVersion | Yes | |
| approvedManifestSha256 | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the read-only, idempotent, non-destructive, non-open-world safety profile. The description adds meaningful behavioral context beyond that: UTF-16 offsets, an 8000-code-unit cap, text-only output, and the fact that code is never executed.
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 tight sentences, front-loads the core lookup action, and packs offset, size, and execution-safety constraints without unnecessary prose.
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?
The tool has rich annotations, an output schema, and only three parameters, so the description does not need to explain return values. It covers the key operational constraints, though it leaves the relationship to bharosa_examples_search and ID acquisition implicit.
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?
With 0% schema description coverage, the description must compensate for all three parameters. It explains that the ID is allowlisted, that offsets are in UTF-16 code units, and that output is capped at 8000 code units, but it does not fully explain offset starting-position semantics, maxChars defaults, or the relationship between the two pagination parameters.
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 states a specific verb and resource: read a canonical example. The phrase 'by allowlisted ID' distinguishes it from the sibling search tool and makes clear it is an ID-based lookup rather than a discovery operation.
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?
Usage is implied by 'by allowlisted ID', which tells the agent an ID is required, but the description does not explicitly say when to use this versus bharosa_examples_search or how to obtain a valid allowlisted ID.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find source-pinned SDK, cURL and guide examples by literal query, language or operation ID. Reports precise synthetic/typecheck/syntax validation scope; no live integration claim.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | Required nonblank literal search text, even when using language or operationId filters. Use the operation ID as query to find its examples. Maximum 120 raw characters. | |
| language | No | ||
| operationId | No |
| Name | Required | Description |
|---|---|---|
| total | Yes | |
| notice | Yes | |
| matches | Yes | |
| reviewedOn | Yes | |
| sdkVersion | Yes | |
| availability | Yes | |
| codingSha256 | Yes | |
| bundleVersion | Yes | |
| codingVersion | Yes | |
| checkpointDate | Yes | |
| contractVersion | Yes | |
| contractSourcePath | Yes | |
| contractSourceSha256 | Yes | |
| publicContractSha256 | Yes | |
| publicContractVersion | Yes | |
| approvedManifestSha256 | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, closed-world, non-destructive, so safety is covered. The description adds a genuinely useful caveat beyond them — that results carry synthetic/typecheck/syntax validation scope and make no live-integration claim — which shapes how an agent should present results. It stops short of noting ordering or whether examples are deduplicated.
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 tight sentences, front-loaded with the verb and resource, followed by the validation-scope qualification. No filler or restatement of the title.
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?
An output schema exists, so return values need no explanation, and the validation-scope caveat completes the honesty picture. Missing is how the four filters combine and what the default result ordering is, which an agent would want 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?
Only 25% schema coverage, so the description must compensate; it names three of the four dimensions (literal query, language, operation ID) which maps to most parameters. However, limit is unmentioned and no enum values or interaction rules (e.g., what language does alongside operationId) are clarified, so the low-coverage gap is only partly closed.
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?
States a specific verb (find) and resource (source-pinned SDK, cURL and guide examples) plus the filtering dimensions. It distinguishes itself from bharosa_docs_search and bharosa_api_search implicitly by naming 'examples' rather than docs or endpoints, but never names a sibling to sharpen the boundary.
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?
Usage is only implied: the query is described as 'literal' and the operation ID can be used as the query, so an agent can infer when to reach for it, but there is no explicit when-to-use versus bharosa_examples_read (fetch by ID) or bharosa_docs_search, and no exclusions.
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.3.2bharosa_api_details3 fields changedOutput schema / properties / bundleVersion / constPrevious value: -"0.2.0-docs.1"New value: +"0.3.2-docs.1"Output schema / properties / codingVersion / constPrevious value: -"0.2.0-coding.1"New value: +"0.3.2-coding.1"Output schema / properties / sdkVersion / constPrevious value: -"0.1.0"New value: +"0.6.0"bharosa_api_search5 fields changedInput schema / properties / method / descriptionAdded value: +"Filter reference documents by their documented HTTP verb. Never executes that method or any network request."Input schema / properties / query / descriptionAdded value: +"Required nonblank literal search text, even when using group or method filters. For monthly API references, try query nav with group monthly. Maximum 120 raw characters."Output schema / properties / bundleVersion / constPrevious value: -"0.2.0-docs.1"New value: +"0.3.2-docs.1"Output schema / properties / codingVersion / constPrevious value: -"0.2.0-coding.1"New value: +"0.3.2-coding.1"Output schema / properties / sdkVersion / constPrevious value: -"0.1.0"New value: +"0.6.0"bharosa_docs_list2 fields changedOutput schema / properties / bundleVersion / constPrevious value: -"0.2.0-docs.1"New value: +"0.3.2-docs.1"Output schema / properties / documents / items / properties / sourcePath / enumPrevious value: -[
- "marketing/src/content/guides.ts",
- "marketing/contracts/openapi.json"
-]New value: +[
+ "marketing/src/content/guides.ts",
+ "marketing/src/content/analytics-guides.ts",
+ "sdk/test/openapi.json",
+ "sdk/test/analytics.openapi.json",
+ "sdk/test/market-search.openapi.json",
+ "marketing/src/content/consent-guide.ts"
+]bharosa_docs_read2 fields changedOutput schema / properties / bundleVersion / constPrevious value: -"0.2.0-docs.1"New value: +"0.3.2-docs.1"Output schema / properties / document / properties / sourcePath / enumPrevious value: -[
- "marketing/src/content/guides.ts",
- "marketing/contracts/openapi.json"
-]New value: +[
+ "marketing/src/content/guides.ts",
+ "marketing/src/content/analytics-guides.ts",
+ "sdk/test/openapi.json",
+ "sdk/test/analytics.openapi.json",
+ "sdk/test/market-search.openapi.json",
+ "marketing/src/content/consent-guide.ts"
+]bharosa_docs_search2 fields changedOutput schema / properties / bundleVersion / constPrevious value: -"0.2.0-docs.1"New value: +"0.3.2-docs.1"Output schema / properties / matches / items / properties / sourcePath / enumPrevious value: -[
- "marketing/src/content/guides.ts",
- "marketing/contracts/openapi.json"
-]New value: +[
+ "marketing/src/content/guides.ts",
+ "marketing/src/content/analytics-guides.ts",
+ "sdk/test/openapi.json",
+ "sdk/test/analytics.openapi.json",
+ "sdk/test/market-search.openapi.json",
+ "marketing/src/content/consent-guide.ts"
+]bharosa_examples_read6 fields changedOutput schema / properties / bundleVersion / constPrevious value: -"0.2.0-docs.1"New value: +"0.3.2-docs.1"Output schema / properties / codingVersion / constPrevious value: -"0.2.0-coding.1"New value: +"0.3.2-coding.1"Output schema / properties / example / properties / language / enumPrevious value: -[
- "typescript",
- "bash",
- "json"
-]New value: +[
+ "typescript",
+ "javascript",
+ "bash",
+ "json"
+]Output schema / properties / example / properties / sdkVersion / constPrevious value: -"0.1.0"New value: +"0.6.0"Output schema / properties / example / properties / validation / enumPrevious value: -[
- "strict-typescript-and-synthetic-transport",
- "strict-typescript",
- "shell-syntax-only",
- "json-parse"
-]New value: +[
+ "strict-typescript-and-synthetic-transport",
+ "strict-typescript",
+ "shell-syntax-only",
+ "javascript-syntax-only",
+ "json-parse"
+]Output schema / properties / sdkVersion / constPrevious value: -"0.1.0"New value: +"0.6.0"bharosa_examples_search8 fields changedInput schema / properties / language / enumPrevious value: -[
- "typescript",
- "bash",
- "json"
-]New value: +[
+ "typescript",
+ "javascript",
+ "bash",
+ "json"
+]Input schema / properties / query / descriptionAdded value: +"Required nonblank literal search text, even when using language or operationId filters. Use the operation ID as query to find its examples. Maximum 120 raw characters."Output schema / properties / bundleVersion / constPrevious value: -"0.2.0-docs.1"New value: +"0.3.2-docs.1"Output schema / properties / codingVersion / constPrevious value: -"0.2.0-coding.1"New value: +"0.3.2-coding.1"Output schema / properties / matches / items / properties / language / enumPrevious value: -[
- "typescript",
- "bash",
- "json"
-]New value: +[
+ "typescript",
+ "javascript",
+ "bash",
+ "json"
+]Output schema / properties / matches / items / properties / sdkVersion / constPrevious value: -"0.1.0"New value: +"0.6.0"Output schema / properties / matches / items / properties / validation / enumPrevious value: -[
- "strict-typescript-and-synthetic-transport",
- "strict-typescript",
- "shell-syntax-only",
- "json-parse"
-]New value: +[
+ "strict-typescript-and-synthetic-transport",
+ "strict-typescript",
+ "shell-syntax-only",
+ "javascript-syntax-only",
+ "json-parse"
+]Output schema / properties / sdkVersion / constPrevious value: -"0.1.0"New value: +"0.6.0"v0.2.0bharosa_api_detailsbharosa_api_searchbharosa_docs_listbharosa_docs_readbharosa_docs_searchbharosa_examples_readbharosa_examples_searchScored across 7 tools
The set splits cleanly into three resource families (api, examples, docs), each with search/read-style operations, so most tools are easy to tell apart. The main soft spot is bharosa_api_search vs bharosa_docs_search, since API reference pages are arguably also bundled docs; the descriptions clarify the difference (API operations vs general doc index) but an agent could still hesitate.
All tools share a predictable bharosa_<resource>_<action> pattern with snake_case throughout. The only deviation is bharosa_api_details, which uses a noun ('details') instead of a verb like read/get, breaking the otherwise uniform verb convention.
Seven tools is well-scoped for a read-only documentation server, with each tool earning its place across three resource families. Nothing feels padded or missing at the count level.
Docs have list/search/read, examples have search/read, and API operations have search/details, covering the core read-only lifecycle. Minor gaps: there is no way to enumerate API operations or list examples directly (only search), so discovery depends on guessing good queries.
Read-only MCP tools for AI agent discovery, structured resources, and NIULAI information.
Pay-per-use tool marketplace for AI agents. Search, price-check, and call APIs via MCP.
Read-only search of 2,189 AI agent tools (MCP servers, x402 APIs) with daily automated trust scores.
Team docs served to AI agents over MCP - search, Markdown reads, version pinning, read audit.
