Martin MCP Toolbox

by 2234839

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation2/5
Several tools have overlapping purposes: siyuan_query_sql and siyuan_database_query both execute SQLite queries on the same tables, read_image and pollinations_analyze_image both analyze images, generate_image and pollinations_generate_image both generate images, and web_search/advanced_web_search are near-duplicates. This causes confusion about which tool an agent should select for a given task.
Naming Consistency3/5
Naming is mixed: some tools follow verb_noun (read_image, update_block) while others use noun_verb (web_search, siyuan_database_query). Prefixes like siyuan_ and pollinations_ are inconsistent, and 'advanced_web_search' does not follow the verb-first pattern of its counterpart.
Tool Count4/5
14 tools is within the reasonable range, but the server spans multiple unrelated domains (SiYuan notes, media AI, web search). The count is not excessive, though it feels like a collection of utilities rather than a focused toolset.
Completeness3/5
For SiYuan notes, query, search, get, and update are covered but create/delete operations are missing. The media tools cover image generation/analysis and video analysis but lack video generation or audio analysis. Web search is adequately covered.
Average 3.3/5 across 14 of 14 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 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
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only says 'Generate an image,' providing no behavioral details such as output format, side effects, rate limits, or public feed implications. This is a significant gap for a tool with 10 parameters.
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?
The description is one sentence and front-loaded, but it is under-specified given the tool's complexity. It is concise but lacks needed information to be considered well-structured.
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 10 parameters and no output schema or annotations, the description is insufficient. It only states the purpose without covering behavior, parameter semantics, or usage context, making it incomplete for an agent to use 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?
Schema description coverage is 100%, so the baseline is 3. The description adds no parameter-specific meaning beyond what the schema provides.
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 generates an image using the Pollinations.AI API, which distinguishes it from text/audio tools. However, it doesn't explicitly differentiate from the sibling 'generate_image' tool.
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 no guidance on when to use this tool versus alternatives, no exclusions, and no context. It only states the basic function.
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 must carry the burden of behavioral disclosure. It mentions the underlying model (GLM-4.5V) but does not disclose behaviors such as output format, latency, cost, or any limitations of video analysis.
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?
The description is a single sentence with no waste, which is structurally clean. However, it is too brief to convey essential context and borders on under-specification, which is not conciseness but rather incompleteness.
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 there are no annotations and no output schema, the description should compensate by explaining what the tool returns, any prerequisites (e.g., video URL format), and typical use cases. It provides none of this, making it insufficient for an AI agent to invoke confidently.
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?
Schema description coverage is 100%, so all parameters are already documented with meaningful descriptions. The tool description adds no extra information about parameters, which is acceptable since the schema fully covers them. Baseline score of 3 is appropriate.
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 states a specific action ('Analyze') and a specific resource ('a video'), which clearly distinguishes it from image-related tools like read_image and pollinations_analyze_image. However, it does not specify what kind of analysis is performed or what aspects of the video are examined, making it somewhat generic.
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 vs alternatives. The sibling tools include image analysis and text generation, but the description does not explain when video analysis is appropriate or mention any alternatives to avoid.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of disclosing behavioral traits. It only restates the action without mentioning rate limits, streaming behavior, privacy implications, or response format. This provides no transparency beyond the basic function.
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 a single concise sentence with no filler or redundant information. It is appropriately brief, though it could benefit from additional structure or elaboration given the tool's complexity.
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?
With 11 parameters, no annotations, and no output schema, the description is severely incomplete. It fails to explain any behavioral context, return values, or usage scenarios, making it inadequate for an agent to understand the tool's full capabilities and side effects.
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?
Schema coverage is 100%, so all 11 parameters have descriptions in the schema. The tool description adds no additional meaning beyond what the schema already provides, so a baseline score of 3 is appropriate.
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 generates text using the Pollinations.AI API. This distinguishes it from sibling tools like pollinations_generate_image and pollinations_generate_audio, which generate other media types.
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 does not mention any exclusions, prerequisites, or alternative tools, leaving the agent to infer usage solely from the tool name.
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 carries full responsibility for behavioral disclosure, but it only states the basic generation action. It does not mention output format, return behavior, saving semantics, costs, rate limits, or any side effects. The timing/quality trade-off is present in the schema, but the description itself adds no behavioral context beyond the obvious.
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?
A single sentence with no fluff, front-loaded with the core action and resource. It is appropriately sized for a tool whose parameters are fully documented in the schema, and every word contributes to meaning.
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 generation tool with no output schema, the description should clarify what the tool returns or saves (e.g., path, URL, base64). The presence of a save_path parameter implies saving, but the description does not confirm this or mention the return value. Combined with sibling ambiguity, the description is incomplete for an agent to invoke it correctly and handle the result.
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 input schema covers 100% of parameters with descriptions, so the baseline is 3. The description adds no new parameter meaning beyond schema, but it does not mislead either. The model name ('CogView-4') is context not directly tied to parameters, but does not enhance parameter understanding.
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 identifies a text-to-image generation tool using the CogView-4 model, with a specific verb ('generate') and resource ('image from text prompt'). However, it does not distinguish itself from the sibling tool pollinations_generate_image, which also generates images, so it lacks explicit sibling differentiation.
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 no guidance on when to use this tool versus the alternative image generation tool or other siblings. It does not mention preferred use cases, exclusions, or conditions that would make this tool the right choice.
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 carries the full burden of disclosing behavioral traits, but it only states that it uses Pollinations.AI Vision API. It does not disclose network requirements, whether both image_url and image_path are supported for different scenarios, output format, or any side effects. The description is minimal and leaves critical behavior unknown.
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 with no unnecessary words. It directly states the tool's purpose and the API used, making it highly concise and front-loaded. Every word contributes value, exemplifying efficient structure.
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?
The tool has 5 parameters, no output schema, and no annotations. The description provides only a high-level summary and lacks information about the return value, how to choose between image_url and image_path, model options, or potential errors. Given the tool's complexity, the description is under-specified and incomplete.
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 input schema provides descriptions for all 5 parameters, and the schema description coverage is 100%. The tool description itself adds no parameter-specific meaning, so it does not enhance the schema. A baseline score of 3 is appropriate when the schema already documents all parameters adequately.
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 uses a specific verb 'Analyze' and names the resource 'image', clearly stating the core action. It also identifies the underlying API (Pollinations.AI Vision API), adding useful context. However, it does not explicitly differentiate itself from sibling tools like 'read_image' or 'generate_image', so it lacks clear sibling differentiation.
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 neither mentions common use cases nor excludes others, such as using 'read_image' for local file reading or 'generate_image' for creation. There are no prerequisites or context clues beyond the basic one-line statement.
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 carries the full burden of behavioral disclosure. It only states 'Analyze an image' without revealing whether the operation is read-only, what kind of output to expect, or any side effects. This lacks critical behavioral transparency.
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, front-loaded sentence with no wasted words. It communicates the core function efficiently and 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?
The tool has no output schema, no annotations, and a minimal description. It does not explain what kind of analysis results are returned, how to formulate prompts, or any context for selecting this over similar image-analysis siblings. This leaves a significant completeness gap.
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 schema covers all 5 parameters with descriptions, so the baseline is 3. The description does not add any parameter-specific meaning, but it doesn't need to because the schema is fully self-documenting.
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 uses the specific verb 'Analyze' and identifies the resource as 'image', with the model name GLM-4.5V adding specificity. It clearly states what the tool does, but does not explicitly differentiate from sibling tool 'pollinations_analyze_image', which also analyzes images.
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 like pollinations_analyze_image or analyze_video. There is no mention of use cases, exclusions, or comparisons.
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 disclose behavioral traits. It does state that IAL metadata is preserved, which is a useful behavior, but it omits critical aspects like whether the update is destructive, whether it can partially fail, any permission requirements, or what happens to other block properties. The mention of preservation is also partially redundant with the preserve_ial parameter, so the added transparency value is limited.
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?
A single sentence that is concise, front-loaded with the action, and includes a meaningful qualifier. No wasted words, and it covers the core purpose effectively.
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 mutation tool with no annotations and no output schema, the description is minimal. It does not explain return values, error behavior, prerequisites (like whether the block_id must exist), or side effects. The presence of two optional boolean parameters (preserve_id, preserve_ial) is not elaborated, and the description does not mention how they affect the update. This leaves significant gaps for an agent to use the tool 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?
Schema coverage is 100%, with all four parameters described individually. The description adds no extra semantic value beyond the schema: 'new content' repeats the data parameter's description, and 'preserving IAL metadata' echoes the preserve_ial parameter. Baseline of 3 is appropriate since the schema already carries the parameter meaning.
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 ('Update a SiYuan note block') and the resource ('note block'), with a specific qualifier about preserving IAL metadata. This is distinct from all sibling tools, which are read/search/generate operations, making the purpose immediately clear.
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 no guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. Sibling tools exist for reading blocks (get_block_kramdown) and searching (siyuan_search_blocks), but the description does not contrast with them or indicate the appropriate context for an update operation.
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 are provided, so the description bears the full burden. It discloses that results are raw and that no automatic synthesis occurs, which is useful behavioral context. However, it omits output format, pagination, rate limits, and any side-effect warnings.
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?
A single, compact sentence in Chinese conveys the core functionality and a key exclusion. It is front-loaded and every word earns its place, making it appropriately concise.
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?
Despite the rich schema, the description is too terse for the tool's context: no output schema, no annotations, and a sibling tool with similar purpose. It lacks guidance on result format, limitations, and relationship to advanced_web_search, leaving gaps for the agent.
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 input schema has 100% coverage with detailed descriptions for all 8 parameters, so the description does not need to explain them. The description adds no parameter-specific semantics beyond what the schema already provides.
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 quick web search and returns raw results, explicitly noting it does not generate articles. This distinguishes it from content-generation tools but does not differentiate it from the sibling 'advanced_web_search'.
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 explicit guidance is provided on when to use this tool versus alternatives like advanced_web_search. The phrase 'raw search results' implies use when structured/summarized output is not needed, but no direct comparison or exclusion is given.
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 must disclose behavioral traits. It mentions optional Sonar and result shaping but does not explain potential side effects, response formats, rate limits, or any safety implications. It lacks details on how the tool modifies results or what happens with Sonar models.
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 a single, front-loaded sentence that is easy to parse and contains no fluff. However, it is so brief that it sacrifices detail; still, it earns a high score for conciseness.
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's complexity (16 parameters, enums, optional Sonar), the description is too minimal. It does not explain return values (no output schema), how result shaping works, nor when to choose different engines like sonar_answer vs raw_search. This leaves significant gaps for an agent to use the tool 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?
Schema description coverage is 100%, so the schema fully documents each of the 16 parameters. The description only generically mentions complex parameters without adding meaning to any specific parameter, so it sits at the baseline of 3.
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 states this is an advanced version of web_search, supporting complex retrieval parameters and result shaping, with optional Sonar direct answers. It clearly identifies the tool's function and distinguishes it from the sibling web_search by emphasizing 'advanced' features.
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 implies advanced_web_search should be used when complex retrieval parameters or Sonar are needed, but does not explicitly state when not to use it or compare with alternatives other than referencing web_search. The phrase '需要时才开' gives a hint to only enable Sonar when necessary, but no clear decision framework.
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 carries the full burden but only states a basic search operation. It does not disclose potential limitations, auth requirements, pagination behavior, or what the response contains.
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, front-loaded sentence with no redundant wording. Every word contributes to understanding the tool's core function.
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?
The tool has no output schema, so the description should explain what the search returns and how pagination works (page parameter). It does neither, leaving the expected response format and behavior unclear for an agent.
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?
All parameters have detailed descriptions in the schema (100% coverage), including an extensive query syntax guide. The tool description itself adds no semantic detail beyond naming full-text search, so the schema carries the parameter explanation.
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 ('Search'), the resource ('blocks in SiYuan notes'), and the method ('full-text search'), which distinguishes it from the sibling tool 'siyuan_query_sql' that uses SQL queries.
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 implies use for full-text search needs but does not provide explicit when-to-use or alternatives comparison. It does not mention exclusions such as 'use siyuan_query_sql for structured queries'.
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 carries full behavioral burden. It states the external API usage but fails to disclose return format, rate limits, authentication needs, or any side effects beyond generation, leaving the agent without critical operational details.
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?
A single, front-loaded sentence that efficiently states the tool's action and API. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and the schema is thorough, but the absence of an output schema and annotations means the description should clarify what the agent receives (audio URL, file, etc.). It doesn't, leaving a gap in operational completeness.
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?
Schema covers all 3 parameters with descriptions and defaults. The description doesn't add extra parameter semantics beyond linking 'text' to the prompt parameter, which is sufficient given high schema 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?
The description uses a specific verb ('Generate'), identifies the resource ('speech audio from text'), and names the API ('Pollinations.AI'), clearly distinguishing it from sibling image/text generation tools.
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?
It clearly indicates the tool is for text-to-speech generation, providing enough context for selection. However, it doesn't mention exclusions or explicitly reference alternatives like generate_image or pollinations_generate_text.
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 carries the full burden. It correctly indicates a read operation via 'Get' and specifies the output format ('kramdown source code'). However, it does not disclose return structure (e.g., how multiple IDs are returned) or error behavior, which is a noticeable gap given no output schema.
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, dense sentence that leads with the verb and object, with no redundant or filler content. Every word contributes to the tool's purpose.
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?
For a simple 1-parameter read operation, the description adequately covers purpose and parameters. It lacks explicit guidance on when to prefer this over sibling tools and omits return format details, but within the tool's low complexity, it is sufficiently complete.
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?
Schema description coverage is 100%, with block_id fully described in the schema. The description adds no extra semantic detail beyond what the schema already provides, so the baseline 3 is appropriate.
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 ('Get'), the resource ('kramdown source code'), and the target ('SiYuan note blocks'), distinguishing it from sibling tools like update_block or siyuan_query_sql. It also accurately notes the capability to fetch one or multiple blocks.
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?
The description implies the use case: when the agent needs raw kramdown source for SiYuan blocks. It doesn't explicitly exclude alternatives like siyuan_query_sql or search, but the purpose is clear enough for an agent to infer appropriate usage.
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 are provided, so the description carries the full burden. It explicitly discloses that only SELECT statements are allowed, prohibits modification statements, and mentions automatic result limiting. This is strong behavioral transparency, though it does not specify the exact result limit or error behavior on invalid queries.
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 well-structured with clear sections (功能说明, 支持的表, 表结构, 示例, 安全注意事项). It is front-loaded with a concise summary, and every section serves a purpose. Despite its length, it remains focused and informative without redundancy.
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?
For a SQL query tool with no output schema, the description is remarkably complete: it covers the tool's purpose, supported tables, full table structures, practical examples, and security constraints. While it doesn't specify the return format, the examples and schema make the expected behavior clear enough for effective use.
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?
Schema coverage is 100%, so the baseline is 3. The description adds significant value by documenting the underlying table schemas (blocks, attributes, refs) and providing SQL examples, which helps construct valid 'stmt' values beyond the schema's brief parameter descriptions.
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 it executes SQLite queries against the SiYuan database (tree/attribute views), with a specific verb and resource. However, it does not distinguish itself from the sibling tool 'siyuan_query_sql', which likely has overlapping functionality, so it misses the sibling differentiation required for a 5.
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?
The description provides clear functional context and multiple usage examples, indicating when to use the tool (to query databases). However, it does not mention any alternative tools or exclusions (e.g., when to use siyuan_query_sql instead), so it lacks explicit when-not guidance.
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 carries full responsibility for behavior disclosure. It details constraints (only block table in default mode, default LIMIT), output formatting (markdown code block), and provides extensive schema documentation. It implies read-only usage but does not explicitly mention error handling or permission requirements.
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 front-loaded with a clear purpose and requirements, then organized into schema documentation, query tips, and examples. It is lengthy but well-structured, with each section contributing practical value for writing SQL. It could be tightened but is not redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description does not explain the tool's return value format, which is a notable gap. It also omits explicit read-only guarantees. However, it is highly comprehensive for writing correct queries, covering schemas, syntax constraints, and examples.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the input schema already describes stmt (100% coverage), the description goes far beyond by documenting the blocks/refs/attributes schemas, field meanings, and offering multiple practical query examples. This greatly enriches the meaning of what a user can pass as a statement.
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 opens with '思源 SQL 查询工具 - 执行 SQLite 查询语句', clearly stating it executes SQLite queries against SiYuan. It distinguishes itself from siblings like siyuan_search_blocks by emphasizing SQL syntax and database schema details.
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?
The description explains when to use embedded-block SQL (must start with select * from blocks) versus advanced API mode, and notes the default LIMIT 64. It provides clear usage context, though it does not explicitly name alternative tools for different query types.
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:

[![mcpserver MCP server](https://glama.ai/mcp/servers/2234839/mcpserver/badges/card.svg)](https://glama.ai/mcp/servers/2234839/mcpserver)

Score Badge

Copy to your README.md:

[![mcpserver MCP server](https://glama.ai/mcp/servers/2234839/mcpserver/badges/score.svg)](https://glama.ai/mcp/servers/2234839/mcpserver)

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/2234839/mcpserver'

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