Token-free MCP server for structured RevoGrid Core, Pro, and Enterprise knowledge retrieval.
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 establish the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false), so the bar is lower. The description adds modest context by framing output as 'implementation evidence' and restricting the result set to runnable or registered examples, which tells the agent what kind of material it will receive. It does not disclose pagination behavior, what 'registered' means, or how the index is versioned, but those are partially visible in the schema, so a 3 is appropriate.
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 17-word sentence with zero filler. The usage trigger is front-loaded before the filter qualifier, and every word earns its place. Nothing is redundant with the schema or annotations.
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 a rich schema (100% parameter coverage, 3 enum-constrained params, cursor/limit pagination) plus an output schema and full annotations, the structured data carries most of the burden. The description completes the picture by stating the resource type and the implementation-evidence context. The only omission is explicit sibling differentiation, which is minor because the sibling resource types (docs, API, capabilities, migration notes) are already distinct.
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 baseline is 3 and the schema already documents all nine parameters including the enums and pagination fields. The description adds only a marginal highlight that framework and package are the salient filters, without contributing format, syntax, or interaction details beyond the schema. This matches the baseline exactly.
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 identifies the resource clearly (runnable or registered RevoGrid examples) and scopes it with framework/package filtering, which differentiates it from siblings like search_revogrid_docs, inspect_revogrid_api, and list_revogrid_capabilities by resource type. However, the verb is only implied through the 'Use when...' construction rather than stated directly as 'Finds/Retrieves...', so it stops short of the full 5.
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...' trigger — when implementation evidence should be a runnable or registered RevoGrid example — which gives strong positive context for tool selection. It does not name sibling alternatives or state exclusions (e.g., when to prefer search_revogrid_docs over this), so it misses the explicit when-not/alternatives requirement for a 5.
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 cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false), and the description adds value beyond them: the anti-guessing behavior ('returns ambiguity candidates instead of guessing') and the response content ('supported import and evidence'). It does not describe no-match behavior, but with annotations present this is a solid disclosure.
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 with zero filler: the first front-loads workflow position and purpose, the second adds the two key behavioral traits. Every word 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?
With an output schema present and annotations covering the safety profile, the description covers purpose, workflow position, ambiguity handling, and output content. It could add guidance on when version/framework/packageName are needed for exact resolution, but the schema documents those parameters and their semantics are 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 fully documents query, version, framework, packageName, and includeInternal. The tool description adds no parameter-level meaning beyond what the schema already provides, so the baseline of 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 pairs a specific verb ('resolve') with a bounded resource ('one exact symbol or capability'), and the qualifiers 'one exact' and 'after discovery' position it against siblings like list_revogrid_capabilities and search_revogrid_docs. An agent can tell this is the targeted lookup tool, not a listing, search, or planning tool.
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?
'Use after discovery' explicitly places the tool in the workflow following capability discovery, which is actionable guidance about when to invoke it. However, it names no sibling alternatives and gives no when-not conditions, so the boundary against tools like search_revogrid_docs must be inferred.
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 cover read-only, idempotent, non-destructive behavior. The description adds useful behavioral context by saying results are compact, paginated summaries linked to detailed resources, which goes beyond the annotations and helps the agent set expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the primary purpose ('Start here'), with no filler or repetition. Every clause contributes either purpose or return-shape context.
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 annotations, complete input schema, and output schema, the description adequately orients the agent for a read-only discovery tool. It covers the core purpose and return shape, though it could add a phrase about filtering dimensions like tier, product, or framework for even stronger completeness.
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 are already documented. The description only loosely maps to parameters via 'paginated' and 'package ownership' but adds no parameter-specific meaning beyond the schema, keeping it at the baseline for full schema coverage.
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 ('discover'), a resource ('supported public capabilities'), and adds 'package ownership', which is more specific than the tool name alone. It positions itself as the starting point, which helps distinguish it from deeper inspection tools, but it does not explicitly differentiate from 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 a clear entry-point context and indicates this tool is for initial discovery of capabilities and ownership. However, it does not state when not to use it or explicitly recommend a sibling tool for alternate needs.
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 establish read-only, idempotent, non-destructive behavior, so the bar for additional disclosure is lower. The description adds useful behavioral context by indicating the output is deterministic and by enumerating what the blueprint includes. 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 a single sentence with no filler. It front-loads the key usage condition ('after resolving capability names') and then names the blueprint's components, giving maximum information density in minimal space.
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 description covers the essential trigger condition and the substance of the output blueprint. Given the presence of a rich output schema, 100% parameter coverage, and annotations describing safety and idempotency, the tool is sufficiently contextualized for an agent to select and invoke it correctly.
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 all seven parameters including requiredCapabilities, constraints, and targetVersions. The description adds no parameter-specific meaning, but the schema carries the full burden, warranting the baseline score of 3.
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 'compose' with a concrete object: a deterministic blueprint covering package, plugin-order, configuration, lifecycle, and compatibility. It clearly states the tool's role in the workflow and distinguishes it from sibling tools like validate_revogrid_usage or inspect_revogrid_api by framing it as post-capability-resolution planning.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to use this tool 'after resolving capability names,' giving clear sequencing context. It does not explicitly name alternatives or exclusion criteria, but the workflow positioning is enough to guide an agent toward when this tool is appropriate relative to siblings.
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, so the safety profile is covered. The description adds valuable behavioral context beyond annotations by stating the tool 'Never executes code' and that it performs 'static' checking with an 'optional bounded source'. This reinforces non-execution and bounded input handling without contradicting 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 two short sentences with no filler. The usage timing is front-loaded, the validation scope is enumerated compactly, and the critical safety constraint 'Never executes code' is stated plainly. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a validation tool with complex optional inputs and an output schema, the description covers the essential context: when to use it, what it validates, and that it is non-executing. The presence of an output schema means return-value details are not required in the description. It could have added a note about expected input combinations, but overall it is sufficiently 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 100%, so the schema already documents all parameters and their meaning. The description generally maps to the parameter groups (imports, configuration, dependencies, versions, source) but adds no parameter-level detail beyond what the schema provides. The baseline of 3 is appropriate because the schema carries the semantic weight.
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, 'statically check', and names the exact scope: RevoGrid imports, configuration, dependencies, versions, and optional bounded source. It also explicitly says 'Never executes code', which helps distinguish it from implementation or runtime-focused siblings. This is clearly differentiated from tools like plan_revogrid_implementation 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?
The description gives an explicit usage context: 'Use before implementation handoff'. It also clarifies a key constraint, that validation is static and never executes code. However, it does not explicitly name alternatives or state when not to use this tool, so it stops short of complete routing guidance.
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_examples1 field changedInput schema / properties / surface / enumPrevious value: -[
- "core",
- "pro",
- "pivot",
- "plugin",
- "columntype",
- "migration",
- "changelog"
-]New value: +[
+ "core",
+ "pro",
+ "pivot",
+ "plugin",
+ "columntype",
+ "migration",
+ "changelog",
+ "internal"
+]search_revogrid_docs1 field changedInput schema / properties / surface / enumPrevious value: -[
- "core",
- "pro",
- "pivot",
- "plugin",
- "columntype",
- "migration",
- "changelog"
-]New value: +[
+ "core",
+ "pro",
+ "pivot",
+ "plugin",
+ "columntype",
+ "migration",
+ "changelog",
+ "internal"
+]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!
Hosted Pro MCP server for RevoGrid DataGrid docs, examples, feature checks, and migration guidance.
MCP server for querying Forkast documentation
MCP server for progressive tool usage at any scale (see https://klavis.ai)
Add one secure layer between your agents and this server.
Each tool targets a distinct stage in the RevoGrid workflow: capability discovery, exact API inspection, broad documentation search, feature-matrix lookup, examples, migration notes, planning, and validation. The discovery-oriented tools overlap somewhat in surface area, but their descriptions clearly separate broad search, exact symbol resolution, and feature-existence checks.
All eight tool names follow a consistent lowercase snake_case verb_noun pattern, such as find_examples, list_revogrid_capabilities, and validate_revogrid_usage. While some names omit the 'revogrid' prefix, the imperative verb + object structure is predictable and uniform.
Eight tools is a well-scoped size for a RevoGrid implementation assistant. Each tool maps to a distinct need from discovery through planning and validation, with no redundant or filler tools.
The server covers the full advisory lifecycle: discover capabilities, search documentation, resolve feature existence, inspect exact APIs, find examples, plan implementations, validate usage, and check migration notes. There are no obvious gaps or dead ends for the stated RevoGrid-focused purpose.
