Hosted Pro MCP server for RevoGrid DataGrid docs, examples, feature checks, and migration guidance.
Use when implementation evidence should be a runnable or registered RevoGrid example, optionally filtered by framework and package.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum examples per page. | |
| query | Yes | Capability or scenario demonstrated by a runnable example. | |
| cursor | No | Opaque cursor returned by the previous page. | |
| product | No | RevoGrid product demonstrated by the example. | |
| surface | No | Legacy catalog surface filter. | |
| version | No | Indexed package version. | |
| framework | No | Preferred example framework. | |
| packageName | No | Exact published npm package name. | |
| requiresPro | No | Filter by descriptive Pro/license requirement. |
| Name | Required | Description |
|---|---|---|
| results | Yes | |
| nextCursor | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already carry the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false), lowering the burden on the description. The description does add one catalog-scoped behavioral trait: results are 'runnable or registered' examples rather than arbitrary matches. It does not disclose pagination behavior via cursor/limit, the meaning of 'registered' versus 'runnable,' or the legacy 'surface' filter, which would have deepened transparency.
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?
A single front-loaded sentence that leads with the invocation condition ('Use when...') and packs the entire semantic scope into roughly 21 words. There is zero filler, and the ordering is ideal: condition first, resource scope second, filters last. Every element 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?
For a 9-parameter tool, the description is minimal, but the 100%-covered schema and presence of an output schema mean parameters and return values need no description-level documentation. The real gap is semantic calibration: 'runnable or registered' is left undefined, and the description never positions the tool against search_revogrid_docs or plan_revogrid_implementation, so an agent entering fresh from a different workflow must infer where 'implementation evidence' begins and ends.
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% — all nine parameters have descriptions, including enums, defaults, and constraints — so the schema carries the full parameter burden. The description adds only that results are 'optionally filtered by framework and package,' which mildly foregrounds the two primary filters but contributes no meaning beyond what the schema already states. Baseline 3 applies.
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 identifies the resource (RevoGrid examples) and the scoping qualifiers ('runnable or registered,' 'optionally filtered by framework and package'), which sets it apart from siblings like search_revogrid_docs and list_revogrid_capabilities by implication. However, the differentiation is implicit — it never explicitly names the sibling it is not, so an agent must infer the boundary between 'examples' and 'docs' or 'capabilities.'
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 opens with an explicit 'Use when...' construction and states the precise invocation condition: when implementation evidence should be a runnable or registered RevoGrid example. This is a clear, actionable context. It does not, however, provide when-not guidance or name alternatives such as search_revogrid_docs for documentation needs, leaving the exclusion logic to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get upgrade notes between RevoGrid versions.
| Name | Required | Description | Default |
|---|---|---|---|
| framework | No | ||
| toVersion | Yes | ||
| fromVersion | Yes |
| Name | Required | Description |
|---|---|---|
| framework | No | |
| toVersion | Yes | |
| fromVersion | Yes | |
| packageChanges | Yes | |
| renamedSymbols | Yes | |
| breakingChanges | Yes | |
| changedDefaults | Yes | |
| recommendedDocs | Yes | |
| recommendedExamples | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds no extra behavioral context such as output format, pagination, or side effects beyond what the annotations and output schema already provide. It is consistent with annotations, so no contradiction.
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 a single, front-loaded sentence with no filler. It communicates the core operation and resource efficiently, and every word contributes to the meaning.
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 annotations and an output schema present, the description does not need to explain return values or safety. However, it lacks contextual guidance for choosing this tool over sibling documentation tools and does not elaborate on the framework parameter, making it minimally adequate rather than complete.
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 compensate. It clarifies that fromVersion and toVersion are version endpoints, but it does not mention the framework parameter at all. The schema's property names and enum cover some meaning, but the description adds minimal value and leaves the optional framework parameter unexplained in prose.
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: 'Get upgrade notes between RevoGrid versions.' This distinguishes it from sibling tools like inspect_revogrid_api or search_revogrid_docs by focusing specifically on version-to-version migration notes, though it does not explicitly name any sibling for contrast.
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 gives no explicit guidance on when to use this tool versus alternatives like search_revogrid_docs or resolve_feature_matrix. The intended use is only implied by the phrase 'upgrade notes between versions,' with no exclusions, prerequisites, or comparison to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use after discovery to resolve one exact symbol or capability. Returns ambiguity candidates instead of guessing and includes its supported import and evidence.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Exact capability, symbol, alias, or package#symbol qualified name. | |
| version | No | Exact indexed package version. | |
| framework | No | Required consumer framework compatibility. | |
| packageName | No | Exact package owner used to disambiguate a symbol. | |
| includeInternal | No | Opt in to unsupported implementation internals; public exports remain preferred. |
| Name | Required | Description |
|---|---|---|
| match | No | |
| status | Yes | |
| candidates | Yes | |
| correction | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish this as a read-only, idempotent, non-destructive operation, so the description does not need to repeat that. The description adds valuable behavioral detail: it returns ambiguity candidates rather than guessing, and includes supported import and evidence. This goes beyond the annotations and helps the agent understand the tool's decision-making behavior.
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 compact and front-loaded with the most important usage constraint, 'Use after discovery.' Every sentence adds value: the first defines the action, the second describes key behavioral guarantees. There is no filler or 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?
Given the output schema, annotations, and fully documented parameters, the description is largely complete for an inspection/resolution tool. It explains when to use it and what behavior to expect. It could slightly improve by explicitly contrasting with search_revogrid_docs or list_revogrid_capabilities, but this is not a significant gap given the context signals.
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%, so the parameters are already well documented in the schema. The description reinforces that the query targets an exact symbol or capability, but does not add substantial meaning beyond the schema. A baseline score of 3 is appropriate since the schema carries the parameter documentation burden.
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 a specific action: resolving one exact symbol or capability, rather than broadly inspecting the API. It also distinguishes itself from sibling discovery/search tools by noting it returns ambiguity candidates instead of guessing. The phrase 'Use after discovery' positions the tool precisely within a 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 gives clear contextual guidance: use it after discovery and for resolving one exact symbol or capability. It does not explicitly name alternatives or state when not to use it, but the context and sibling tool names make the intended usage reasonably clear. This is strong but not fully explicit about exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start here to discover supported public capabilities and package ownership. Returns compact paginated summaries linked to detailed resources.
| Name | Required | Description | Default |
|---|---|---|---|
| tier | No | Core, Pro, or Enterprise package tier. | |
| limit | No | Maximum compact capability summaries per page. | |
| cursor | No | Opaque cursor returned by the previous page. | |
| product | No | Restrict capability ownership to one product. | |
| version | No | Exact indexed package version. | |
| framework | No | Consumer framework the capability must support. | |
| stability | No | Stable, experimental, or deprecated capability status. | |
| packageName | No | Exact published npm package name. |
| Name | Required | Description |
|---|---|---|
| results | Yes | |
| nextCursor | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds modest context about returning compact paginated summaries linked to detailed resources, but it does not disclose much beyond that; no contradiction with annotations exists.
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 short sentences with no wasted content. The key entry-point signal 'Start here' is front-loaded, and every phrase adds 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?
The tool has a fully documented input schema, an output schema, rich annotations, and no required parameters. The description provides sufficient entry-point framing and output expectations without needing to repeat structured information already present.
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%, so all eight parameters already have descriptions in the schema. The tool description adds no parameter-specific semantics, so the baseline 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 uses a specific verb ('discover') and names a concrete resource ('supported public capabilities and package ownership'). It also states the output shape ('compact paginated summaries linked to detailed resources'), making it clearly distinguishable from siblings like search_revogrid_docs or inspect_revogrid_api.
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?
'Start here' gives an explicit entry-point instruction, which is useful for an agent deciding where to begin. However, it does not name alternative sibling tools or state when those alternatives should be preferred, so exclusion guidance is absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use after resolving capability names to compose a deterministic package, plugin-order, configuration, lifecycle, and compatibility blueprint.
| Name | Required | Description | Default |
|---|---|---|---|
| framework | No | Consumer application framework. | vanilla |
| objective | Yes | Concrete data-grid behavior to implement. | |
| constraints | No | Architecture, licensing, performance, or compatibility constraints. | |
| capabilities | No | Compatibility alias for requiredCapabilities. | |
| targetVersions | No | Desired versions keyed by npm package name. | |
| installedVersions | No | Currently installed versions keyed by npm package name. | |
| requiredCapabilities | No | Exact capabilities or aliases required by the objective. |
| Name | Required | Description |
|---|---|---|
| events | Yes | |
| imports | Yes | |
| methods | Yes | |
| dataFlow | Yes | |
| evidence | Yes | |
| packages | Yes | |
| warnings | Yes | |
| framework | Yes | |
| lifecycle | Yes | |
| objective | Yes | |
| unresolved | Yes | |
| constraints | Yes | |
| pluginOrder | Yes | |
| configuration | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the 'deterministic' nature of the blueprint, which is mildly useful context, but it does not disclose side effects, permissions, failure modes, or other behavioral traits beyond what annotations provide.
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 a single front-loaded sentence with no wasted words. It states the precondition ('Use after resolving capability names') before the output deliverable, and every phrase contributes to purpose or usage.
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 complexity, the description is minimal, but the rich schema and output schema carry the detailed parameter and return-structure information. The main missing element is an explicit tie to sibling tools for routing, though the precondition 'after resolving capability names' partially compensates by signaling the correct workflow position.
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%, so the schema documents all 7 parameters. The description only gives a high-level sense that parameters feed into 'package, plugin-order, configuration, lifecycle, and compatibility' blueprint categories, but it does not add parameter-level 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?
The description names a specific action ('compose') and a concrete deliverable: 'a deterministic package, plugin-order, configuration, lifecycle, and compatibility blueprint.' This clearly distinguishes the tool from siblings that inspect, search, resolve, or validate. The phrase 'Use after resolving capability names' also anchors its role 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?
It provides a clear precondition and usage context: use only after capability names have been resolved, which points to resolution-stage sibling tools. However, it does not explicitly name alternatives or state when not to use this tool, so it lacks the full when/when-not routing that would earn a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resolve whether a RevoGrid feature exists, whether it is Pro, and where to learn it.
| Name | Required | Description | Default |
|---|---|---|---|
| version | No | ||
| framework | No | ||
| featureName | Yes |
| Name | Required | Description |
|---|---|---|
| notes | Yes | |
| bestDocs | Yes | |
| stability | No | |
| supported | Yes | |
| featureName | Yes | |
| requiresPro | Yes | |
| bestExamples | Yes | |
| fallbackApproach | No | |
| supportedFrameworks | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds context by specifying the resolution outputs, but it does not disclose details such as the data source or whether the resolution is static. No contradiction with annotations.
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 a single, front-loaded sentence with no filler. It states the action and the three key outcomes clearly, making every word carry meaning.
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 output schema and annotations cover the return shape and safety profile, which reduces the burden on the description. However, the description does not explain how the optional version and framework parameters influence the lookup, nor does it position the tool against its seven siblings. Adequate but not fully complete.
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 compensate. It implies that featureName is the core parameter, but it gives no explanation of how version or framework affect the feature matrix resolution. The agent is left to infer their meaning from the schema's enum and optionality.
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 ('Resolve') and names the exact outputs: whether a RevoGrid feature exists, whether it is Pro, and where to learn it. This is clear enough to differentiate it from broader siblings like list_revogrid_capabilities, though it does not explicitly name any alternative.
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 explicit guidance on when to use this tool versus alternatives like search_revogrid_docs or validate_revogrid_usage. The intended usage is implied by the action verb, but no prerequisites, exclusions, or routing conditions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use for broad RevoGrid questions or when the exact API name is unknown. Searches source-grounded docs and API evidence; defaults to public exports.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum results per page. | |
| query | Yes | RevoGrid concept, API symbol, package, or implementation question. | |
| cursor | No | Opaque cursor returned by the previous page. | |
| product | No | Restrict results to one RevoGrid product. | |
| surface | No | Legacy catalog surface filter. | |
| version | No | Restrict results to an indexed package version. | |
| docTypes | No | Restrict source kinds such as API, guide, or example. | |
| framework | No | Restrict results to a consumer framework. | |
| symbolKind | No | Restrict exported declaration kind. | |
| visibility | No | Defaults to public; internal requires explicit internal selection. | |
| packageName | No | Exact published npm package name. | |
| requiresPro | No | Filter by descriptive Pro/license requirement. |
| Name | Required | Description |
|---|---|---|
| query | Yes | |
| results | Yes | |
| nextCursor | No | |
| appliedFilters | Yes | |
| suggestedNextTool | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnly, idempotent, and non-destructive behavior, so the safety profile is covered. The description adds useful behavioral context by noting that searches are 'source-grounded' and that results 'default to public exports,' going beyond the structured annotations.
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, each earning its place: the first gives the primary use case and the second describes the search source and default scope. Information is front-loaded and there is no redundancy 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?
Given the rich input schema, annotations, and output schema, the description is sufficiently complete for selecting and invoking the tool. It covers the core use case and default behavior, though it could name sibling tools to further reduce ambiguity.
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%, so the input schema already documents all 12 parameters. The description adds little semantic value for parameters, though the phrase 'defaults to public exports' does reinforce the visibility parameter's default behavior. Baseline 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 the tool's purpose: searching RevoGrid documentation and API evidence. It specifies the verb ('search'), the resource ('source-grounded docs and API evidence'), and the intended use case ('broad RevoGrid questions or when the exact API name is unknown'), which distinguishes it from more targeted sibling tools.
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 context for when to use the tool: for broad questions or when the exact API name is unknown. It implies that a more precise tool should be used when the exact API is known, but it does not explicitly name sibling alternatives or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use before implementation handoff to statically check structured RevoGrid imports, configuration, dependencies, versions, and optional bounded source. Never executes code.
| Name | Required | Description | Default |
|---|---|---|---|
| imports | No | Structured imports to validate without execution. | |
| features | No | Capabilities the application intends to use. | |
| framework | No | Consumer application framework. | |
| configuration | No | Configuration keys grouped by their owning capability. | |
| sourceSnippet | No | Optional bounded source used only for static import inspection; never executed. | |
| installedVersions | No | Installed versions keyed by npm package name. |
| Name | Required | Description |
|---|---|---|
| valid | Yes | |
| diagnostics | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, and the description reinforces this with 'statically check' and 'Never executes code,' adding a stronger execution guarantee. It also notes the source is 'bounded,' providing input constraints not present in annotations.
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 short sentences with the most important usage timing and full scope list front-loaded. The second sentence 'Never executes code' is a critical safety property stated with zero waste.
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 6-parameter tool with an output schema and rich annotations, the description covers the key contextual signals: when to run it, what it validates, and its non-execution guarantee. It omits return-value details, but those are presumably captured in the output schema, and the sibling context makes its role clear.
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%, so the schema already documents each parameter fully. The description adds a high-level grouping of inputs (imports, configuration, dependencies, versions, bounded source) that helps map intent, but it provides no per-parameter details 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 uses the specific verb 'statically check' against concrete resources: structured RevoGrid imports, configuration, dependencies, versions, and optional bounded source. It clearly aligns with the tool's name and differentiates it from sibling tools like plan_revogrid_implementation or inspect_revogrid_api by framing it as a validation step before handoff.
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 opening phrase 'Use before implementation handoff' provides a clear trigger condition for when to invoke the tool. It doesn't explicitly name alternatives or state when not to use it, but the workflow placement is unambiguous and gives enough context.
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. Dates show when Glama detected each change.
find_examples12 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesRemoved value: -falseInput schema / properties / cursorAdded value: +{
+ "description": "Opaque cursor returned by the previous page.",
+ "type": "string"
+}Input schema / properties / framework / descriptionAdded value: +"Preferred example framework."Input schema / properties / limit / descriptionAdded value: +"Maximum examples per page."Input schema / properties / packageNameAdded value: +{
+ "description": "Exact published npm package name.",
+ "type": "string"
+}Input schema / properties / productAdded value: +{
+ "description": "RevoGrid product demonstrated by the example.",
+ "enum": [
+ "core",
+ "pro",
+ "pivot",
+ "gantt",
+ "scheduler",
+ "kanban",
+ "collaboration",
+ "enterprise"
+ ],
+ "type": "string"
+}Input schema / properties / query / descriptionAdded value: +"Capability or scenario demonstrated by a runnable example."Input schema / properties / requiresPro / descriptionAdded value: +"Filter by descriptive Pro/license requirement."Input schema / properties / surface / descriptionAdded value: +"Legacy catalog surface filter."Input schema / properties / version / descriptionAdded value: +"Indexed package version."Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": false,
+ "properties": {
+ "nextCursor": {
+ "type": "string"
+ },
+ "results": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "exampleUrl": {
+ "format": "uri",
+ "type": "string"
+ },
+ "framework": {
+ "enum": [
+ "react",
+ "vue",
+ "angular",
+ "svelte",
+ "vanilla"
+ ],
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "packages": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "requiresPro": {
+ "type": "boolean"
+ },
+ "score": {
+ "type": "number"
+ },
+ "sourceUrl": {
+ "type": "string"
+ },
+ "summary": {
+ "type": "string"
+ },
+ "surface": {
+ "enum": [
+ "core",
+ "pro",
+ "pivot",
+ "plugin",
+ "columntype",
+ "migration",
+ "changelog",
+ "internal"
+ ],
+ "type": "string"
+ },
+ "title": {
+ "type": "string"
+ },
+ "version": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "title",
+ "surface",
+ "requiresPro",
+ "summary",
+ "packages",
+ "score"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "results"
+ ],
+ "type": "object"
+}get_migration_notes3 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesRemoved value: -falseOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": false,
+ "properties": {
+ "breakingChanges": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "changedDefaults": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "framework": {
+ "enum": [
+ "react",
+ "vue",
+ "angular",
+ "svelte",
+ "vanilla"
+ ],
+ "type": "string"
+ },
+ "fromVersion": {
+ "type": "string"
+ },
+ "packageChanges": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "recommendedDocs": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "authority": {
+ "type": "number"
+ },
+ "docType": {
+ "enum": [
+ "guide",
+ "api",
+ "example",
+ "live-demo",
+ "migration",
+ "faq"
+ ],
+ "type": "string"
+ },
+ "exampleUrl": {
+ "format": "uri",
+ "type": "string"
+ },
+ "framework": {
+ "enum": [
+ "react",
+ "vue",
+ "angular",
+ "svelte",
+ "vanilla"
+ ],
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "packageName": {
+ "type": "string"
+ },
+ "packageVersion": {
+ "type": "string"
+ },
+ "product": {
+ "enum": [
+ "core",
+ "pro",
+ "pivot",
+ "gantt",
+ "scheduler",
+ "kanban",
+ "collaboration",
+ "enterprise"
+ ],
+ "type": "string"
+ },
+ "requiresPro": {
+ "type": "boolean"
+ },
+ "score": {
+ "type": "number"
+ },
+ "snippet": {
+ "type": "string"
+ },
+ "sourcePath": {
+ "type": "string"
+ },
+ "sourceRevision": {
+ "type": "string"
+ },
+ "summary": {
+ "type": "string"
+ },
+ "surface": {
+ "enum": [
+ "core",
+ "pro",
+ "pivot",
+ "plugin",
+ "columntype",
+ "migration",
+ "changelog",
+ "internal"
+ ],
+ "type": "string"
+ },
+ "symbolKind": {
+ "enum": [
+ "class",
+ "function",
+ "interface",
+ "type",
+ "enum",
+ "variable",
+ "event",
+ "plugin",
+ "component",
+ "unknown"
+ ],
+ "type": "string"
+ },
+ "symbols": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "title": {
+ "type": "string"
+ },
+ "url": {
+ "format": "uri",
+ "type": "string"
+ },
+ "version": {
+ "type": "string"
+ },
+ "visibility": {
+ "enum": [
+ "public",
+ "internal"
+ ],
+ "type": "string"
+ },
+ "whyMatched": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "title",
+ "summary",
+ "surface",
+ "docType",
+ "requiresPro",
+ "symbols",
+ "score",
+ "snippet",
+ "url"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "recommendedExamples": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "exampleUrl": {
+ "format": "uri",
+ "type": "string"
+ },
+ "framework": {
+ "enum": [
+ "react",
+ "vue",
+ "angular",
+ "svelte",
+ "vanilla"
+ ],
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "packages": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "requiresPro": {
+ "type": "boolean"
+ },
+ "score": {
+ "type": "number"
+ },
+ "sourceUrl": {
+ "type": "string"
+ },
+ "summary": {
+ "type": "string"
+ },
+ "surface": {
+ "enum": [
+ "core",
+ "pro",
+ "pivot",
+ "plugin",
+ "columntype",
+ "migration",
+ "changelog",
+ "internal"
+ ],
+ "type": "string"
+ },
+ "title": {
+ "type": "string"
+ },
+ "version": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "title",
+ "surface",
+ "requiresPro",
+ "summary",
+ "packages",
+ "score"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "renamedSymbols": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "from": {
+ "type": "string"
+ },
+ "to": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "from",
+ "to"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "toVersion": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "fromVersion",
+ "toVersion",
+ "breakingChanges",
+ "renamedSymbols",
+ "changedDefaults",
+ "packageChanges",
+ "recommendedDocs",
+ "recommendedExamples"
+ ],
+ "type": "object"
+}inspect_revogrid_apilist_revogrid_capabilitiesplan_revogrid_implementationresolve_feature_matrix3 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesRemoved value: -falseOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": false,
+ "properties": {
+ "bestDocs": {
+ "default": [],
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "authority": {
+ "type": "number"
+ },
+ "docType": {
+ "enum": [
+ "guide",
+ "api",
+ "example",
+ "live-demo",
+ "migration",
+ "faq"
+ ],
+ "type": "string"
+ },
+ "exampleUrl": {
+ "format": "uri",
+ "type": "string"
+ },
+ "framework": {
+ "enum": [
+ "react",
+ "vue",
+ "angular",
+ "svelte",
+ "vanilla"
+ ],
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "packageName": {
+ "type": "string"
+ },
+ "packageVersion": {
+ "type": "string"
+ },
+ "product": {
+ "enum": [
+ "core",
+ "pro",
+ "pivot",
+ "gantt",
+ "scheduler",
+ "kanban",
+ "collaboration",
+ "enterprise"
+ ],
+ "type": "string"
+ },
+ "requiresPro": {
+ "type": "boolean"
+ },
+ "score": {
+ "type": "number"
+ },
+ "snippet": {
+ "type": "string"
+ },
+ "sourcePath": {
+ "type": "string"
+ },
+ "sourceRevision": {
+ "type": "string"
+ },
+ "summary": {
+ "type": "string"
+ },
+ "surface": {
+ "enum": [
+ "core",
+ "pro",
+ "pivot",
+ "plugin",
+ "columntype",
+ "migration",
+ "changelog",
+ "internal"
+ ],
+ "type": "string"
+ },
+ "symbolKind": {
+ "enum": [
+ "class",
+ "function",
+ "interface",
+ "type",
+ "enum",
+ "variable",
+ "event",
+ "plugin",
+ "component",
+ "unknown"
+ ],
+ "type": "string"
+ },
+ "symbols": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "title": {
+ "type": "string"
+ },
+ "url": {
+ "format": "uri",
+ "type": "string"
+ },
+ "version": {
+ "type": "string"
+ },
+ "visibility": {
+ "enum": [
+ "public",
+ "internal"
+ ],
+ "type": "string"
+ },
+ "whyMatched": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "title",
+ "summary",
+ "surface",
+ "docType",
+ "requiresPro",
+ "symbols",
+ "score",
+ "snippet",
+ "url"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "bestExamples": {
+ "default": [],
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "exampleUrl": {
+ "format": "uri",
+ "type": "string"
+ },
+ "framework": {
+ "enum": [
+ "react",
+ "vue",
+ "angular",
+ "svelte",
+ "vanilla"
+ ],
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "packages": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "requiresPro": {
+ "type": "boolean"
+ },
+ "score": {
+ "type": "number"
+ },
+ "sourceUrl": {
+ "type": "string"
+ },
+ "summary": {
+ "type": "string"
+ },
+ "surface": {
+ "enum": [
+ "core",
+ "pro",
+ "pivot",
+ "plugin",
+ "columntype",
+ "migration",
+ "changelog",
+ "internal"
+ ],
+ "type": "string"
+ },
+ "title": {
+ "type": "string"
+ },
+ "version": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "title",
+ "surface",
+ "requiresPro",
+ "summary",
+ "packages",
+ "score"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "fallbackApproach": {
+ "type": "string"
+ },
+ "featureName": {
+ "type": "string"
+ },
+ "notes": {
+ "default": [],
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "requiresPro": {
+ "type": "boolean"
+ },
+ "stability": {
+ "enum": [
+ "stable",
+ "experimental",
+ "deprecated"
+ ],
+ "type": "string"
+ },
+ "supported": {
+ "type": "boolean"
+ },
+ "supportedFrameworks": {
+ "items": {
+ "enum": [
+ "react",
+ "vue",
+ "angular",
+ "svelte",
+ "vanilla"
+ ],
+ "type": "string"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "featureName",
+ "supported",
+ "requiresPro",
+ "supportedFrameworks",
+ "notes",
+ "bestDocs",
+ "bestExamples"
+ ],
+ "type": "object"
+}search_revogrid_docs15 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesRemoved value: -falseInput schema / properties / cursorAdded value: +{
+ "description": "Opaque cursor returned by the previous page.",
+ "type": "string"
+}Input schema / properties / docTypes / descriptionAdded value: +"Restrict source kinds such as API, guide, or example."Input schema / properties / framework / descriptionAdded value: +"Restrict results to a consumer framework."Input schema / properties / limit / descriptionAdded value: +"Maximum results per page."Input schema / properties / packageNameAdded value: +{
+ "description": "Exact published npm package name.",
+ "type": "string"
+}Input schema / properties / productAdded value: +{
+ "description": "Restrict results to one RevoGrid product.",
+ "enum": [
+ "core",
+ "pro",
+ "pivot",
+ "gantt",
+ "scheduler",
+ "kanban",
+ "collaboration",
+ "enterprise"
+ ],
+ "type": "string"
+}Input schema / properties / query / descriptionAdded value: +"RevoGrid concept, API symbol, package, or implementation question."Input schema / properties / requiresPro / descriptionAdded value: +"Filter by descriptive Pro/license requirement."Input schema / properties / surface / descriptionAdded value: +"Legacy catalog surface filter."Input schema / properties / symbolKindAdded value: +{
+ "description": "Restrict exported declaration kind.",
+ "enum": [
+ "class",
+ "function",
+ "interface",
+ "type",
+ "enum",
+ "variable",
+ "event",
+ "plugin",
+ "component",
+ "unknown"
+ ],
+ "type": "string"
+}Input schema / properties / version / descriptionAdded value: +"Restrict results to an indexed package version."Input schema / properties / visibilityAdded value: +{
+ "description": "Defaults to public; internal requires explicit internal selection.",
+ "enum": [
+ "public",
+ "internal"
+ ],
+ "type": "string"
+}Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": false,
+ "properties": {
+ "appliedFilters": {
+ "additionalProperties": false,
+ "properties": {
+ "cursor": {
+ "type": "string"
+ },
+ "docTypes": {
+ "items": {
+ "enum": [
+ "guide",
+ "api",
+ "example",
+ "live-demo",
+ "migration",
+ "faq"
+ ],
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "framework": {
+ "enum": [
+ "react",
+ "vue",
+ "angular",
+ "svelte",
+ "vanilla"
+ ],
+ "type": "string"
+ },
+ "limit": {
+ "maximum": 20,
+ "minimum": 1,
+ "type": "integer"
+ },
+ "packageName": {
+ "type": "string"
+ },
+ "product": {
+ "enum": [
+ "core",
+ "pro",
+ "pivot",
+ "gantt",
+ "scheduler",
+ "kanban",
+ "collaboration",
+ "enterprise"
+ ],
+ "type": "string"
+ },
+ "requiresPro": {
+ "type": "boolean"
+ },
+ "surface": {
+ "enum": [
+ "core",
+ "pro",
+ "pivot",
+ "plugin",
+ "columntype",
+ "migration",
+ "changelog",
+ "internal"
+ ],
+ "type": "string"
+ },
+ "symbolKind": {
+ "enum": [
+ "class",
+ "function",
+ "interface",
+ "type",
+ "enum",
+ "variable",
+ "event",
+ "plugin",
+ "component",
+ "unknown"
+ ],
+ "type": "string"
+ },
+ "version": {
+ "type": "string"
+ },
+ "visibility": {
+ "enum": [
+ "public",
+ "internal"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "limit"
+ ],
+ "type": "object"
+ },
+ "nextCursor": {
+ "type": "string"
+ },
+ "query": {
+ "type": "string"
+ },
+ "results": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "authority": {
+ "type": "number"
+ },
+ "docType": {
+ "enum": [
+ "guide",
+ "api",
+ "example",
+ "live-demo",
+ "migration",
+ "faq"
+ ],
+ "type": "string"
+ },
+ "exampleUrl": {
+ "format": "uri",
+ "type": "string"
+ },
+ "framework": {
+ "enum": [
+ "react",
+ "vue",
+ "angular",
+ "svelte",
+ "vanilla"
+ ],
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "packageName": {
+ "type": "string"
+ },
+ "packageVersion": {
+ "type": "string"
+ },
+ "product": {
+ "enum": [
+ "core",
+ "pro",
+ "pivot",
+ "gantt",
+ "scheduler",
+ "kanban",
+ "collaboration",
+ "enterprise"
+ ],
+ "type": "string"
+ },
+ "requiresPro": {
+ "type": "boolean"
+ },
+ "score": {
+ "type": "number"
+ },
+ "snippet": {
+ "type": "string"
+ },
+ "sourcePath": {
+ "type": "string"
+ },
+ "sourceRevision": {
+ "type": "string"
+ },
+ "summary": {
+ "type": "string"
+ },
+ "surface": {
+ "enum": [
+ "core",
+ "pro",
+ "pivot",
+ "plugin",
+ "columntype",
+ "migration",
+ "changelog",
+ "internal"
+ ],
+ "type": "string"
+ },
+ "symbolKind": {
+ "enum": [
+ "class",
+ "function",
+ "interface",
+ "type",
+ "enum",
+ "variable",
+ "event",
+ "plugin",
+ "component",
+ "unknown"
+ ],
+ "type": "string"
+ },
+ "symbols": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "title": {
+ "type": "string"
+ },
+ "url": {
+ "format": "uri",
+ "type": "string"
+ },
+ "version": {
+ "type": "string"
+ },
+ "visibility": {
+ "enum": [
+ "public",
+ "internal"
+ ],
+ "type": "string"
+ },
+ "whyMatched": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "title",
+ "summary",
+ "surface",
+ "docType",
+ "requiresPro",
+ "symbols",
+ "score",
+ "snippet",
+ "url"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "suggestedNextTool": {
+ "enum": [
+ "search_revogrid_docs",
+ "find_examples",
+ "resolve_feature_matrix",
+ "get_migration_notes",
+ "inspect_revogrid_api",
+ "plan_revogrid_implementation"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "query",
+ "appliedFilters",
+ "results"
+ ],
+ "type": "object"
+}validate_revogrid_usagefind_examples1 field changedInput schema / properties / requiresProAdded value: +{
+ "type": "boolean"
+}find_examplesget_migration_notesresolve_feature_matrixsearch_revogrid_docsClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Token-free MCP server for structured RevoGrid Core, Pro, and Enterprise knowledge retrieval.
Hosted MCP server for AI-driven data ops. Create apps, manage schemas, and CRUD structured data.
GrapeCity Software MCP for SpreadJS docs, examples, and product assistance.
Hosted MCP server for real-world data: business registries, sanctions, companies, domains, crypto.
Add one secure layer between your agents and this server.
Most tools have clearly distinct purposes, especially the action-oriented workflow tools like plan and validate. The main ambiguity is among the discovery/query tools—list_revogrid_capabilities, resolve_feature_matrix, search_revogrid_docs, and inspect_revogrid_api—though their descriptions provide enough guidance to avoid frequent misselection.
All tool names follow a consistent snake_case verb_noun pattern, such as find_examples, inspect_revogrid_api, and validate_revogrid_usage. The verbs clearly indicate the action, and the naming style is uniform across the entire set.
Eight tools is well-scoped for a RevoGrid implementation-assistance server. Each tool serves a meaningful step in the discovery-to-validation workflow without excessive redundancy or a feeling of missing core functionality.
The toolset covers the full knowledge-workflow lifecycle: discover capabilities, resolve feature existence, search docs, inspect exact APIs, find examples, get migration notes, plan implementation, and validate usage. This is a comprehensive surface for the stated purpose, with no obvious dead ends.