ragic-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct operation (CRUD, search, list sheets, lock/unlock, approve, filter help) with no overlap. An agent can easily distinguish them.
Naming Consistency5/5
All tool names follow a consistent `ragic_verb_noun` pattern (e.g., ragic_create_record, ragic_list_sheets). No mixing of conventions.
Tool Count5/5
With 11 tools, the set is well-scoped for a database client, covering essential operations without superfluous tools.
Completeness5/5
The tools provide full CRUD, search, sheet discovery, locking, and approval—covering the core Ragic workflow. No obvious gaps for the intended purpose.
Average 3.3/5 across 11 of 11 tools scored. Lowest: 2.5/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 9 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must disclose behavioral traits. It only states 'unlock' without mentioning permissions, effects of unlocking a non-locked record, or state changes. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no fluff, but it is overly concise and omits critical details, making it less effective than a slightly longer description would be.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given three required parameters, no output schema, and no annotations, the description is highly incomplete. It fails to explain the record identity, unlocking prerequisites, or return behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must explain parameters. It does not define path, sheet_index, or record_id, leaving the agent without essential context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (unlock) and resource (record), and it differentiates from sibling tools such as ragic_lock and ragic_approve by specifying a distinct operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool (e.g., only for locked records) or its relationship to ragic_lock. The agent has no context on prerequisites or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present. The description only mentions the 'fts' parameter, giving minimal insight into behavioral traits like side effects, authorization needs, or performance implications. For a search tool, it is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, consisting of a single sentence. It is efficient with no wasted words, but could benefit from additional context without sacrificing brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 parameters, no output schema, and no annotations, the description is incomplete. It does not explain pagination (limit/offset), response format, or how the 'fts' parameter interacts with the query.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no explanation for the six parameters beyond the hint about the 'fts' parameter. With 0% schema description coverage, the description fails to clarify the meaning or usage of parameters like 'path', 'sheet_index', 'limit', 'offset', or 'naming'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs full-text search on a sheet, referencing the Ragic 'fts' parameter. However, it does not differentiate from sibling tools like 'ragic_list_records' or 'ragic_get_record'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description lacks context for when full-text search is appropriate compared to list or filter operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states the immediate effect ('prevent further edits') but does not disclose side effects, permissions needed, or behavior if the record is already locked.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One short sentence is concise, but it omits critical information that should be present. It is not well-structured for completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given three parameters and no annotations or output schema, the description is incomplete. It lacks details on parameter formats, prerequisites, and behavioral context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description adds no information about the three required parameters ('path', 'record_id', 'sheet_index'). The agent has no guidance on what values to pass.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Lock'), the resource ('a record'), and the effect ('prevent further edits'). It distinguishes itself from the sibling tool 'ragic_unlock' by implication.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use or when not to use this tool versus alternatives like 'ragic_unlock' or 'ragic_approve'. Usage is implied but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description should disclose behavioral traits. It identifies the action as destructive but does not mention authentication needs, reversibility, error behavior, or success/failure responses. The no-batch note is helpful but insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with two sentences, front-loading the primary action. However, it may be too brief given the lack of parameter explanations and usage context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a delete operation with three required parameters and no output schema or annotations, the description is incomplete. It fails to clarify parameter roles, return values, or error conditions, leaving significant gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description offers no explanation for the three required parameters (path, record_id, sheet_index). Since schema description coverage is 0%, the description should compensate, but it adds no meaning beyond the parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Delete a record' with a specific verb and resource, and distinguishes from siblings like ragic_create_record and ragic_update_record. The additional note about batch delete adds clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions that batch delete is not supported, implying when not to use this tool. However, it does not explicitly state when to use this tool versus alternatives, nor does it provide contexts such as prerequisites or side effects.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool is read-only ('Read one record') and specifies the input key (`_ragicId`). However, with no annotations provided, the description carries the full burden. It fails to mention behavioral traits like what happens if the record is not found, required permissions, rate limits, or the structure of the response. The detail about the ID source adds some transparency, but overall it is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently conveys the core action and key input. It is front-loaded with the verb and resource, containing no unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's 9 parameters, no output schema, and no annotations, the description is grossly incomplete. It does not explain the return format, error behavior, the meaning of optional parameters, or how the tool fits into a workflow (e.g., 'Use after getting `_ragicId` from `ragic_list_records`'). This leaves an AI agent with significant gaps for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 9 parameters with 0% schema description coverage. The description only mentions `record_id` implicitly via `_ragicId`. It does not explain the purpose of `path`, `sheet_index`, or the boolean flags (`info`, `naming`, `history`, `approval`, `subtables`, `ignore_mask`). For a tool with many optional parameters, this is severely lacking and provides almost no value beyond the schema's property titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Read one record') and the resource ('by its Ragic node id'). It specifies the identifier field (`_ragicId` in list responses), which distinguishes it from sibling tools like `ragic_list_records` (multiple records) and `ragic_create_record` (write operation).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives (e.g., `ragic_search` or `ragic_list_records` with filters). The description implies you need the record ID from a list response, but does not state prerequisites, when to avoid, or context like 'Use this for fetching a single known record; for bulk retrieval, use `ragic_list_records`.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey behavioral traits. It reveals that the tool modifies approval status but omits side effects, required permissions, reversibility, or potential notifications. Minimal disclosure beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and to the point, with no extraneous words. It could be more structured, but it effectively conveys core information in two sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with five parameters, no annotations, and no output schema, the description leaves significant gaps: three required parameters are unexplained, and there is no mention of the tool's role in the approval workflow or any prerequisites. The agent lacks essential context to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning for two parameters: specifying valid values for 'action' and clarifying 'comment' as optional response text. However, three required parameters (path, record_id, sheet_index) remain undescribed. Given 0% schema coverage, the description partially compensates but is incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Approve or reject a record awaiting approval.' This distinguishes it from sibling tools like ragic_update_record or ragic_lock, which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides parameter constraints (action must be 'approve' or 'reject', comment is optional) but offers no guidance on when to use this tool versus alternatives like ragic_update_record. No context about prerequisites or expected record states is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It states the auth requirement (write permission) and field format but does not disclose return value, error handling, or whether the operation is idempotent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is relatively concise with 3 sentences, front-loading the purpose. It uses line breaks for readability, but could be more structured with parameter details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 10 parameters, no output schema, and no annotations, the description is incomplete. It covers field format but omits many parameter semantics and behavioral details needed for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% for 10 parameters. Only the 'fields' parameter is partially described (numeric keys, subtables). Other parameters like path, check_lock, do_formula, etc., are not explained in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Create a new record' with specific verb and resource. It adds context about field format (numeric IDs) and subtables, which distinguishes it from other operations like update or delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description mentions required write permission and references ragic_filter_help() for subtables. However, it does not explicitly state when to use this tool over alternatives like ragic_update_record, or provide exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description adds behavioral detail on check_lock preventing silent overwrite, but omits other traits like authentication needs, rate limits, or effects of extra booleans (do_formula, do_workflow, etc.).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: the first states purpose, the second adds critical lock behavior. No unnecessary words, front-loaded essential info.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 11 parameters and no output schema or annotations, the description leaves most parameters undefined (e.g., path, sheet_index, do_workflow). Only check_lock is covered, so the agent lacks sufficient context to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only check_lock is explained in the description; the remaining 10 parameters (including required fields, fields object, do_formula, etc.) receive no semantics beyond the schema names, which have 0% coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Update fields of an existing record' with the specific caveat 'Only the provided fields change,' distinguishing it from creation or deletion siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like ragic_create_record or ragic_lock; the description only explains check_lock behavior without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It explicitly states 'Read records' indicating non-destructive behavior. While it does not explicitly guarantee safety, the verb 'read' adequately conveys the operation type. No contradiction detected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is a single paragraph with helpful line breaks, no wasted words. Purpose is front-loaded. Includes a reference to a cheatsheet for additional details, which is efficient. Could be more structured but is appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 13 parameters and no output schema, description is insufficient. It omits explanation for many parameters (e.g., limit, offset, info). Agent lacks full understanding of all options, risking incorrect tool use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, requiring description to compensate. Description covers only 3 of 13 parameters (path, sheet_index, where) in detail, leaving limit, offset, order, info, naming, etc. unexplained. Parameter semantics are incomplete for an AI agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description starts with 'Read records from a Ragic sheet' clearly stating verb (read) and resource (records from a sheet). It distinguishes from sibling tools like ragic_create_record (create) and ragic_delete_record (delete) by specifying read-only operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description explains how to construct path and sheet_index from URL and details where parameter usage, but does not explicitly state when to use this tool versus alternatives like ragic_get_record or ragic_search. Usage context is implied but not comparative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description fully discloses that it returns a cheatsheet, is read-only, and intended for initial setup. No hidden behaviors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two succinct sentences with front-loaded purpose. No extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given it's a help tool with no inputs, description covers what it returns (syntax, IDs, format, limits). Output schema exists but not detailed; description compensates with specific topics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so the description adds value by explaining what the tool returns (syntax cheatsheet with specific topics). Schema coverage is 100%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns a cheatsheet for Ragic filter/write parameters. It is distinct from sibling tools which perform specific CRUD operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises reading at the start of a Ragic task to understand syntax, field IDs, and rate limits. Does not mention alternatives, but context makes it clear this is a documentation tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It clearly describes the output and that no arguments are needed. It implies a read-only operation (listing) but does not explicitly state no side effects. The description is adequate but could be more explicit about being safe/idempotent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: three sentences, each purposeful. First sentence states the main action, second details output format, third gives usage instructions. No redundancy or extra words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters, no annotations, and no output schema, the description is complete. It explains what the tool does, the output structure, and how to use it in a workflow. No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so schema coverage is trivially 100%. With 0 parameters, baseline is 4. The description correctly notes 'No arguments,' so no additional parameter info is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'List every sheet the configured API key can see, grouped by tab.' It specifies the output structure (tree: account -> tabs -> sheets) and differentiates from siblings by indicating it's the first call to find a sheet by Chinese name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this as the FIRST call when the user asks about a sheet by Chinese name — find it in the tree, then use the matching path & sheet_index for subsequent tools.' This provides clear when-to-use and what-to-do-next guidance. Also states 'No arguments. The user doesn't need to paste a URL anymore.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![ragic-mcp MCP server](https://glama.ai/mcp/servers/EthanH9977/ragic-mcp/badges/card.svg)](https://glama.ai/mcp/servers/EthanH9977/ragic-mcp)

Score Badge

Copy to your README.md:

[![ragic-mcp MCP server](https://glama.ai/mcp/servers/EthanH9977/ragic-mcp/badges/score.svg)](https://glama.ai/mcp/servers/EthanH9977/ragic-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/EthanH9977/ragic-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server