Softbowl SBGrid3.0 데이터 그리드(grid)의 공식 API 문서를 검색해, AI가 정확한 그리드 코드를 생성하도록 돕습니다.
Get the full documentation for one SBGrid3.0 API/option by its exact name: syntax, all sub-options, detailed explanation, and a code example. Use after searchSBGridAPI once you know the exact name. ⚠️ SBGrid3 코드/샘플 생성 시 서버 공통지침(표준 골격에서 출발 · columns/gridConfig 리터럴 나열 · 요청 기능만 최소 적용) 준수 — 상세는 서버 instructions 참고.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Exact API/option name as shown in searchSBGridAPI results (e.g. 'excelExport', 'columns', 'personalization'). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses the tool returns syntax, sub-options, explanation, and code example, plus includes a note about SBGrid3 code generation guidelines, adding useful behavioral context.
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, front-loaded with core purpose. Second sentence adds relevant usage guidance and caution, though slightly tangential. Overall concise and effective.
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 one-param tool with no output schema, the description adequately explains what is returned and when to use it. No mention of read-only behavior, but annotations are absent and context is sufficient for selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one parameter 'name' described as 'Exact API/option name as shown in searchSBGridAPI results'. Description reiterates this but adds no new meaning beyond the schema, so baseline 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 a specific verb ('Get') and resource ('full documentation for one SBGrid3.0 API/option') and distinguishes from sibling tools like searchSBGridAPI (search) and getSBGridExample (examples).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'Use after searchSBGridAPI once you know the exact name', providing clear when-to-use guidance. Does not specify alternatives or when-not, but context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find runnable SBGrid3.0 code examples by feature or use case. Returns ready-to-adapt example snippets. Use when you want working sample code rather than the API reference. ⚠️ SBGrid3 코드/샘플 생성 시 서버 공통지침(표준 골격에서 출발 · columns/gridConfig 리터럴 나열 · 요청 기능만 최소 적용) 준수 — 상세는 서버 instructions 참고.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of examples to return. Default 3. | |
| query | Yes | Feature or use case to find examples for (e.g. 'excel export', 'row grouping', 'cell editing'). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations present; description includes a warning about server guidelines for code generation, adding behavioral context, but does not mention read-only nature or other traits.
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 plus a supplemental warning; front-loaded with purpose, but the Korean warning may be slightly extraneous.
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?
Adequately covers purpose, usage, and behavioral note for a simple tool with no output schema; minor gap in describing return format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and description adds context about query being a feature/use case and limit being max number default 3, but does not significantly extend beyond 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?
Describes specific verb 'Find' and resource 'runnable SBGrid3.0 code examples', clearly distinguishing from sibling tools like listSBGridAPIs and searchSBGridAPI.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
States 'Use when you want working sample code rather than the API reference', providing explicit guidance on when to use this over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Browse the SBGrid3.0 API surface by category. Call with no argument to get all top-level categories; pass a category to list the APIs under it. Use to explore what exists when you don't have a specific keyword. ⚠️ SBGrid3 코드/샘플 생성 시 서버 공통지침(표준 골격에서 출발 · columns/gridConfig 리터럴 나열 · 요청 기능만 최소 적용) 준수 — 상세는 서버 instructions 참고.
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | Category to list APIs for (optional). Omit to return the list of all categories. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. The description explains the browsing behavior but does not mention any potential side effects, safety profile, or authentication needs. The Korean warning relates to a separate context and adds confusion rather than 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?
The core description is concise, but the Korean warning about SBGrid3 code/sample generation is tangential and takes up space without helping the agent use this tool. It could be removed or moved to a separate note.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and lack of output schema, the description covers the basic functionality and usage. However, it does not describe the return format (e.g., list of strings) or any pagination, which could be helpful for an agent. The extraneous warning does not contribute to 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?
The schema description of the 'category' parameter is already clear, but the tool description adds context by explaining 'top-level categories' vs 'APIs under it', enhancing the semantic meaning beyond the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: browsing the SBGrid3.0 API surface by category. It specifies the verb 'browse' and the resource 'API surface', and distinguishes itself from siblings like searchSBGridAPI and getSBGridAPIDetail.
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 explicit guidance on when to use the tool ('when you don't have a specific keyword') and how to invoke it with or without the category argument. However, it does not explicitly mention when not to use it or reference alternatives, though the sibling context makes that clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search SBGrid3.0 grid API and option documentation by keyword. Returns matching entries with name, summary, syntax, and category. Start here to find which API/option fits a task, then call getSBGridAPIDetail for full details or getSBGridExample for code. ⚠️ SBGrid3 코드/샘플 생성 시 서버 공통지침(표준 골격에서 출발 · columns/gridConfig 리터럴 나열 · 요청 기능만 최소 적용) 준수 — 상세는 서버 instructions 참고.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results to return. Default 5. | |
| query | Yes | Keyword to search: a feature, option, or method name (e.g. 'excelExport', 'filter', 'column width', 'row grouping'). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations; description adds a warning about code generation guidelines, which is behavioral context. Does not disclose rate limits or pagination for results, but the schema covers limit parameter.
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 plus a relevant warning. Information is front-loaded: purpose first, then usage flow. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with 2 parameters and no output schema, the description provides enough context: what to search, what results contain, and how it fits with siblings. Could mention default limit behavior, but limit is documented in schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description does not add significant new detail beyond the schema, but it does contextualize the query as a keyword for API documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Explicitly states it searches SBGrid API documentation by keyword. Distinguishes from siblings by positioning as the starting point and naming getSBGridAPIDetail and getSBGridExample for next steps.
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?
Clearly states to start here and then proceed to sibling tools for details or examples. No explicit when-not-to-use, but the context implies this is for initial exploration.
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.
getSBGridAPIDetail1 field changedInput schema / properties / name / descriptionPrevious value: -"Exact API name"New value: +"Exact API/option name as shown in searchSBGridAPI results (e.g. 'excelExport', 'columns', 'personalization')."getSBGridExample2 fields changedInput schema / properties / limit / descriptionAdded value: +"Maximum number of examples to return. Default 3."Input schema / properties / query / descriptionPrevious value: -"Feature or use case"New value: +"Feature or use case to find examples for (e.g. 'excel export', 'row grouping', 'cell editing')."listSBGridAPIs1 field changedInput schema / properties / category / descriptionAdded value: +"Category to list APIs for (optional). Omit to return the list of all categories."searchSBGridAPI2 fields changedInput schema / properties / limit / descriptionAdded value: +"Maximum number of results to return. Default 5."Input schema / properties / query / descriptionPrevious value: -"Search keyword"New value: +"Keyword to search: a feature, option, or method name (e.g. 'excelExport', 'filter', 'column width', 'row grouping')."getSBGridAPIDetailgetSBGridExamplelistSBGridAPIssearchSBGridAPIClaiming 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!
Softbowl SBChart2.0 차트(chart) 라이브러리의 공식 API 문서를 검색해, AI가 정확한 차트 코드를 생성하도록 돕습니다.
Checks AI-written SvGrid code against the real API, plus version-pinned Svelte 5 grid docs.
Hosted Pro MCP server for RevoGrid DataGrid docs, examples, feature checks, and migration guidance.
AI coding assistant for Radzen Blazor — docs, APIs, code samples, and templates for 100+ components.
Add one secure layer between your agents and this server.
Each tool serves a distinct function: searching, listing categories, getting detailed API documentation, and retrieving example code. There is no overlap in purpose.
All tool names follow a consistent verb_noun pattern (e.g., getSBGridAPIDetail, searchSBGridAPI), making the set predictable and easy to navigate.
With 4 tools, the set is well-scoped for exploring API documentation. Each tool earns its place, covering search, browse, detail, and examples without redundancy or gaps.
The tools cover the full lifecycle of accessing documentation: search to find, list to browse, get detail for reference, and get example for code. No obvious missing operations.
