Hosted Pro MCP server for RevoGrid DataGrid docs, examples, feature checks, and migration guidance.
Scored across 8 tools
Each tool serves a distinct phase of the workflow: discovery, search, exact API resolution, feature matrix, planning, validation, examples, and migration. Descriptions clearly delineate boundaries, so agents can reliably select the right tool without ambiguity.
All names follow a consistent verb_noun snake_case pattern (e.g., find_examples, list_revogrid_capabilities, validate_revogrid_usage). Verbs are specific and nouns match the domain resource, creating a predictable and scannable naming scheme.
With 8 tools, the surface is well-scoped for a specialized data-grid MCP server. It covers discovery, search, resolution, planning, validation, examples, and migration without redundancy or unnecessary bloat, fitting comfortably in the ideal range.
The tool set provides a complete lifecycle for RevoGrid implementation: from initial discovery (list_revogrid_capabilities), through search and resolution (search_revogrid_docs, resolve_feature_matrix, inspect_revogrid_api), to planning and validation (plan_revogrid_implementation, validate_revogrid_usage), plus supporting materials (find_examples, get_migration_notes). No obvious dead ends or missing operations for the stated purpose.
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 well covered. The description adds no extra behavioral context beyond the basic lookup action, but it does not contradict the 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. Every word contributes to the core purpose, and it is appropriately sized for a simple lookup tool.
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?
While annotations and output schema cover safety and return structure, the description is missing key context such as what version formats are accepted, the role of the framework parameter, and when to prefer this tool over sibling doc/example tools. It is minimally 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%, and the description only loosely maps to fromVersion/toVersion by saying 'between RevoGrid versions.' It does not explain version format expectations, nor does it clarify the optional 'framework' parameter's meaning or filtering role, leaving a significant 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?
The description uses a specific verb ('Get') and resource ('upgrade notes between RevoGrid versions') that clearly identify the tool's function. It is distinct from siblings like find_examples or search_revogrid_docs, though it does not explicitly differentiate itself.
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 no guidance about when to use this tool versus alternatives such as search_revogrid_docs or validate_revogrid_usage. There are no stated conditions, exclusions, or prerequisites, leaving the agent to infer appropriate use from the name alone.
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 safe, read-only nature is established. The description adds useful behavioral detail by specifying what the resolution returns: existence, Pro status, and a learning resource. It does not address unknown-feature edge cases or framework/version sensitivity, but the annotation coverage lowers the burden here.
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 sentence with no filler. It front-loads the core lookup question and packs the three answer dimensions into a compact, scannable form.
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 read-only lookup with an output schema, the description gives the essential purpose. Yet in a toolset with eight similar RevoGrid tools, the missing usage guidance and undocumented optional parameters leave meaningful gaps, so the description is only minimally sufficient rather than fully self-contained.
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 would need to compensate. It only implies the main parameter by mentioning 'a RevoGrid feature,' which maps to featureName, but it never explains the optional `version` or `framework` parameters or how they influence the resolution. The schema itself provides only types and an enum, not semantics.
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 action ('Resolve'), the resource ('a RevoGrid feature'), and the three output dimensions: existence, Pro status, and learning resource. However, it does not explicitly distinguish this tool from siblings like search_revogrid_docs or list_revogrid_capabilities, so it stops short of full differentiation.
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 about when to use this tool versus the many sibling tools, nor any 'use this instead of...' guidance. The phrase 'where to learn it' weakly implies a docs-lookup purpose, but it does not help an agent choose between this and search_revogrid_docs or find_examples.
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?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds useful context beyond annotations: results are 'source-grounded' and visibility 'defaults to public exports.' This clarifies what the search operates over and the default access scope, which helps an agent interpret results correctly.
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 concise sentences with no filler. The primary use condition is front-loaded, and the search scope is stated efficiently. Every word contributes to agent understanding.
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 12-parameter search tool with full schema descriptions and an output schema, the description is sufficient for tool selection. It could briefly mention pagination or result structure, but the structured schema and annotations already cover most operational details. The main gap is not explicitly distinguishing from search siblings, but the usage condition handles that reasonably.
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 12 parameters are already documented with meaningful descriptions. The tool description does not need to repeat them, but it also adds no extra parameter-level semantics beyond the schema. Baseline 3 is appropriate because the schema carries the full 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?
States a specific verb ('search') and resource ('source-grounded docs and API evidence'), and explicitly frames its use case as broad RevoGrid questions or unknown exact API names. This clearly distinguishes it from sibling tools like inspect_revogrid_api without needing to open the 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?
The description gives a clear context for use: broad questions or when the exact API name is unknown. It does not explicitly name the alternative for exact API lookups, but the stated condition implies that a more targeted sibling tool should be used when the exact API is known. It could be improved by naming inspect_revogrid_api directly.
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.
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_docsToken-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.
The official MCP server for Capawesome documentation and Capawesome Cloud.
Add one secure layer between your agents and this server.