ScientificFigureLibrary

by xuzhougeng

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: v0.3.0
Disambiguation3/5
Several tools involve copying or importing content (import, plan_import, apply_import, materialize, upsert, sync), and their boundaries can blur. The legacy direct-write import overlaps with the plan/apply pair, and materialize vs. upsert both create/replace templates, requiring careful reading of descriptions.
Naming Consistency5/5
All tools follow a strict figure_library_<verb> pattern in lower snake_case. Multi-word verbs like plan_import and apply_import are consistent and readable. No mixed conventions or stylistic deviations.
Tool Count4/5
With 15 tools, the server is at the upper edge of the ideal range. The count is justified by the broad lifecycle (status, describe, search, import, sync, audit, reconcile), but the legacy import tool is redundant with plan/apply, making the set feel slightly larger than necessary.
Completeness4/5
The tool surface covers search, import, creation/update, archive, preview, audit, and reconciliation, which is comprehensive for a figure library. Minor gaps exist: no direct 'list all' tool (search must be used) and no hard delete, but archiving and audit/reconcile cover most operational needs.
Average 4/5 across 15 of 15 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 7 commits in the last 12 weeks
- Last stable release on August 1, 2026
- 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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, and non-destructive behavior, so the description doesn't need to repeat those. It adds context about what is inspected (effective paths, counts, Source Pack details), but doesn't elaborate on side effects or environmental dependencies. No contradiction with annotations.
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 sentence that efficiently packs multiple pieces of information without wasted words. However, the dense phrasing of 'lifecycle/integrity counts' makes it slightly less accessible, preventing a perfect score.
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?
The presence of an output schema and high schema coverage reduces the description's burden. The description covers the main functions effectively, though terms like 'lifecycle/integrity counts' are left undefined; overall adequate for an agent to understand the tool's scope.
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?
Input schema covers 100% of parameter descriptions with clear definitions for sourcePackDir and galleryDirectory. The description adds little parameter-specific meaning, only implicitly linking them to the reported paths and Source Pack, so the baseline 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 specifies concrete actions: reporting effective User Library and Gallery paths, lifecycle/integrity counts, and inspecting a Source Pack by file name and size. This goes beyond the generic title, but it doesn't explicitly differentiate itself from sibling tools like 'audit' or 'reconcile', keeping it from 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description simply states what it reports, leaving the agent to infer usage context without explicit context, exclusions, or alternative tool naming.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds the behavior of reading every manifest and verifying files, plus the explicit guarantee that recommendations never modify the library, which is useful but mostly aligns with the annotations. No contradiction.
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 two sentences, front-loaded with the core action and scope, and ends with the non-modification guarantee. No filler or redundant information.
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?
There is an output schema and the core function is described, but the description lacks explanation of the 'includeArchived' parameter and does not differentiate this tool from the similar 'figure_library_reconcile' sibling. It is adequate but leaves gaps for a multi-tool environment.
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?
With 0% schema coverage, the description must compensate for parameter meaning. It indirectly hints at the 'scope' enum values by mentioning invalid, legacy, and duplicate evidence, but it does not name the parameter or explain 'includeArchived'. This 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 reads every user-template manifest, verifies stored files, and reports invalid, legacy, and duplicate evidence. It uses specific action verbs and a defined resource, and explicitly notes it never modifies the library, distinguishing it from mutation-type siblings.
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 usage for auditing and checking the library, and the non-modification note hints at when not to use it. However, it does not explicitly state alternatives (e.g., reconcile) or give clear 'when to use vs. not use' 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?
Annotations already provide idempotentHint=true and destructiveHint=false, and the description adds key behavioral context by disclosing that imported code is copied but never executed. This addresses a major safety concern and goes beyond the structured annotations, though further details about side effects or error handling are absent.
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 two short, front-loaded sentences with no redundant information. The core action and safety property are presented succinctly, making it easy to parse and remember.
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 complexity (21 parameters, nested objects, 5 required fields, output schema), the description omits critical context about the broader workflow, such as how the plan digest is validated, what happens if validation fails, and how this relates to figure_library_plan_import or figure_library_import. The output schema helps with return values, but not with usage flow or failure behavior.
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%, so the description carries no parameter-level guidance. It does not explain the required fields like planDigest, expectedAction, expectedTemplateId, or operationId, nor the nested duplicateResolution/sourceConflictResolution structures, leaving agents to rely only on 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 the tool applies a confirmed direct import plan using the exact confirmed create/update/duplicate decision, distinguishing it from sibling tools like figure_library_plan_import or figure_library_import. It also adds a valuable safety qualifier that imported code is copied but never executed.
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 phrase 'confirmed direct import plan' implies this should be used after a plan has been approved, but it does not explicitly state when to use this tool versus alternatives or mention any exclusions. The usage context is only implied, not fully articulated.
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?
The description adds meaningful behavioral context beyond sparse annotations: apply uses verified preconditions, a shared write lock, a recovery journal, and explicitly states files are retained. This aligns with destructiveHint=false and gives useful safety details, though it could mention side effects of rollback.
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 tightly written sentences, with the first front-loading the core action modes and the second adding critical safety mechanisms. Every sentence earns its place; no filler.
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 complex tool with 7 parameters, a nested expectedState object, and no schema descriptions, this description is too sparse. It omits guidance on how to fill required fields, what the exact duplicate conditions are, and what the output schema represents. An agent would struggle to invoke it correctly without additional documentation.
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%, so the description must compensate. It only mentions the mode concept (dry-run/apply/rollback) but does not explain the six required parameters such as reconcileId, expectedState, canonicalTemplateId, or the nested structure of expectedState. The agent cannot derive parameter meaning from the description.
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 performs dry-run, apply, or rollback of an exact duplicate-archive transaction. It distinguishes itself from siblings by focusing on reconciliation via archiving, with a specific verb and resource.
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?
Usage is implied through 'duplicate-archive transaction' and the mention of dry-run/apply/rollback modes, but no explicit comparison to alternatives like figure_library_archive or figure_library_diff is provided. There is no guidance on when not to use this 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds value by detailing the internal steps: validating files, calculating stable identity and duplicate evidence, and producing a concurrency-bound plan. It reinforces the no-write behavior ('No files are written') without contradicting annotations.
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 two sentences, front-loaded with the primary action, and every clause serves a purpose. It is concise yet informative, and the explicit 'No files are written' is a valuable clarity addition.
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?
An output schema exists, so return values are covered elsewhere. The description gives the high-level purpose but lacks context on how parameters map to file paths, what 'direct-import files' means, or the relationship to sibling import tools. It is adequate for a planning tool but leaves several operational gaps.
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%, so the description must compensate, but it provides no explanation of any of the 15 parameters. It mentions 'direct-import files' without linking them to parameters like codePaths or imagePath, and does not clarify how input fields influence the plan. The description adds no meaning beyond the schema's raw property 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 the tool's function: 'Read and validate direct-import files, calculate stable identity and duplicate evidence, and return a concurrency-bound plan.' It specifies a concrete verb (read/validate/calculate/return) and resource (direct-import files, plan), and distinguishes itself from siblings like figure_library_import or figure_library_apply_import by emphasizing it only plans and writes nothing.
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 conveys clear context: this is a planning stage that performs no writes, which implicitly indicates it should be used before actually importing. However, it does not explicitly name alternatives or provide when-not-to-use guidance, so it stops short of a full 5.
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?
Adds meaningful behavioral context beyond annotations: dryRun defaults true, applying imports approved entries, skips drafts, and logically archives archived entries. This is consistent with idempotentHint=true and destructiveHint=false, and provides concrete filtering logic.
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 concise sentences front-load the core purpose and then add critical behavioral detail. No wasted words; every sentence earns its place.
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 synchronization tool with 8 optional parameters and combined plan/apply behavior, the description is too thin. It lacks details about the relationship between planning and applying, return values, error conditions, or how 'stable imports' are achieved. The output schema helps but the description does not sufficiently cover the tool's complexity.
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?
With schema coverage at only 13%, the description partially compensates by explaining dryRun's default and the reviewStatus-driven behavior (approved/draft/archived). However, it does not elaborate on language, assetKind, codeStatus, plotFamily, sourceCommit, or galleryDirectory beyond the schema's own note.
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 validates a Gallery and plans stable imports, then explains the apply behavior (imports approved, skips drafts, archives archived). This distinguishes it as a sync tool that combines planning and applying, unlike sibling tools like plan_import or apply_import.
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 usage for gallery synchronization, mentioning dryRun and apply behavior, but does not explicitly contrast with sibling tools like plan_import or apply_import. There is no when-not-to-use guidance or alternative recommendations.
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?
Annotations already indicate non-destructive and idempotent behavior; the description adds valuable context by clarifying that files are retained and that the tool never hard-deletes. This goes beyond the annotations by explaining the practical consequence of archiving.
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 two sentences with no filler. The first sentence states the core action and identifier resolution, the second adds retention behavior. Every word earns its place.
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 description covers purpose, identifier resolution, and retention behavior. However, with all input parameters optional, it leaves ambiguity about parameter selection and precedence. It also does not mention any side effects beyond archiving, though the output schema likely handles return-value details.
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 0%, so the description must compensate. It explains the meaning of templateId, galleryId, and registrySourceId ('adapter-scoped'), but does not clarify the 'adapter' parameter or whether exactly one identifier is required when multiple are provided. The description adds some semantic value but omits important composition details.
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 clearly identifies the action ('archive') and resource ('user-library template'), and the primary effect ('exclude the template from default search'). It also distinguishes this tool from deletion by explicitly stating 'Files are retained; this tool never hard-deletes a template.'
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 usage by explaining the archival effect and acceptable identifier types, but it does not explicitly state when to prefer this tool over siblings or list exclusions. It lacks direct alternatives or 'use this instead' guidance.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description echoes 'read-only' but adds no new behavioral context such as error handling, auth requirements, or limitations. Since annotations cover the safety profile, this is neutral and adequate.
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 unnecessary wording. Every word adds value, efficiently conveying the tool's purpose and scope.
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 the tool's low complexity (one parameter), existing output schema, and strong annotations, the description is complete. It clearly states what the tool does and for which input, without needing to explain return values because the output schema covers that.
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 0%, so the description must compensate. It mentions 'one exact template ID,' which clarifies the role of the templateId parameter but provides no additional format or source information. For a single self-explanatory parameter, this is minimally sufficient.
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 'Return' as a specific verb and clearly identifies the resource: 'structured, read-only details for one exact template ID.' It distinguishes from sibling tools like search by emphasizing 'one exact template ID,' indicating a single-item retrieval operation.
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 clearly implies when to use this tool: when you have a specific template ID and need structured details. It does not explicitly mention exclusions or alternatives, but the context is clear enough for a simple look-up 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?
Annotations already declare readOnlyHint=true and destructiveHint=false, and the description reinforces this with 'read-only' and 'No files are imported'. It adds context about the reviewable nature of the diff and the validation aspect, which goes beyond the annotations. No contradictions.
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, front-loaded with the primary action and key constraint. Every word adds value, with no redundancy or fluff.
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 description covers purpose and behavior adequately, but with 0% parameter schema coverage, it does not fully explain the parameters or which combinations are valid. The output schema exists, so return values are covered, but the optional parameters and the 'one ... or' relationship could confuse an agent. More detail would improve 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?
The input schema has three parameters with zero descriptions (0% coverage). The description mentions 'Figure Transfer Package or Gallery entry', which hints at galleryPath/packagePath, but does not explain sourceCommit, nor does it clarify that only one source should be provided. It partially compensates but leaves gaps.
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 'Diff' and identifies the resource ('import source against the User Library'). It clearly distinguishes from siblings by stating 'No files are imported' and 'read-only', contrasting with import/materialize tools. The purpose is immediately understandable.
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 context for when to use this tool: when you need to validate or preview a diff without importing. The explicit 'No files are imported' serves as a when-not, though no alternative tool is named. This is sufficient guidance for an AI agent.
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?
Annotations already declare the tool as read-only, idempotent, and non-destructive. The description adds the behavioral nuance that opening the workbench does not involve searching, which is a usage hint rather than a new safety trait. It does not add significant behavioral disclosure beyond what annotations provide, so a mid-range score is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that conveys both purpose and usage context without any filler. It is front-loaded with the main action ('Open the template workbench') and then clarifies the condition. Every word contributes to understanding, making it highly concise and well-structured.
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 the tool's simplicity (no parameters, output schema exists), the description is largely sufficient. It explains the primary purpose and the key condition for use. However, it could be slightly more complete by elaborating what 'template workbench' refers to or what 'plotting intent' means, but within the context of the sibling tools, it is adequately complete.
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?
The tool has zero parameters, so the baseline is 4. The description correctly focuses on the action rather than parameters, and there is no need to explain parameter semantics since none exist. The schema confirms an empty object, and the description adds no conflicting information.
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 function: 'Open the template workbench.' It further specifies the context ('when no plotting intent exists'), which distinguishes it from sibling search tools. This is a specific verb+resource with scope, clearly separating it from the family.
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 explicitly indicates when to use this tool: when there is no plotting intent, implying you should not use search. It names the alternative indirectly ('inventing a search'), which is clear but not as explicit as naming the exact sibling tool. Could be improved by directly saying 'use figure_library_search when plotting intent exists.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint=false, openWorldHint=true), the description adds vital behavioral details: 'Never overwrites or executes code' and the explicit instruction to halt on errors. These are not implied by annotations and significantly inform the agent's safety and error recovery behavior.
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 exceptionally concise: two sentences. The first sentence delivers the core purpose, and the second conveys critical safety constraints. No filler or redundant statements—every sentence earns its place.
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 the presence of a rich input schema (80% parameter descriptions) and an output schema, the description is sufficient for an agent to invoke the tool correctly. It adds crucial safety context not in annotations. A minor gap is not explicitly explaining when the 'template' vs 'full' modes are appropriate, but the schema already covers this.
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 descriptions cover 80% of parameters (mode, destination, allowNetwork, sourcePackDir), including specific details like 'creates destination/<templateId>' and 'fails instead of trying mirrors.' The tool description itself does not add parameter-specific meaning, but with such high schema coverage, it does not need to compensate.
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 function: 'Copy a selected user template or acquire a commit-pinned FigureYa archive.' This specifies a distinct action (copy/acquire) and resource, differentiating it from sibling tools like figure_library_import or figure_library_sync. The added constraints 'Never overwrites or executes code' further clarify its scope.
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 gives clear context on when to use the tool (when a template needs to be materialized) and includes critical error-handling guidance ('stop immediately, report it, and do not retry...'). However, it does not explicitly mention alternative tools or when not to use this tool, relying on the agent to infer from the action described.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds important behavioral nuance: it expects compact derived profiles rather than raw data, which is a significant operational constraint. This goes beyond the schema by explaining the intended input transformation. No contradiction with annotations.
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 two sentences: the first states the purpose, the second provides a critical usage rule. Every word earns its place, and the instruction is front-loaded. No redundancy or filler.
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?
With an output schema present, the description does not need to explain return values. The description covers core behavior: what is searched, when to use, and how to format input. It omits mention of optional filters (assetKind, sourceIds, etc.), but these are visible in the schema. Given the tool's complexity, the description is adequate, though a brief nod to filtering could make it more complete.
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 50%, so the description must compensate. The instruction 'Pass compact derived profiles, never an entire dataset' directly clarifies the role of dataProfile and visualProfile, which the schema already describes as summaries. It reinforces the meaning of these key parameters. While some parameters (e.g., limit, language) remain undocumented in the description, their names and schema properties are self-explanatory. The added value is meaningful enough for a 4.
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 function: 'Search FigureYa and user-imported references.' The verb 'search' is specific, the resource is identified, and the tool is distinct from sibling tools like import, apply, or diff. The context 'after analyzing the user's image, text, or data' adds purpose without ambiguity.
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 contextual guidance: this tool should be used after analyzing the user's input, and it instructs to 'Pass compact derived profiles, never an entire dataset.' This tells the agent when and how to call it. It does not explicitly mention alternatives or exclusions, but the context is strong enough for a 4.
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?
The description discloses both the primary behavior (returning image content) and an important side effect (optionally copying to a project-local directory). This adds context beyond the annotations, which only indicate idempotent and non-destructive behavior. It does not cover failure modes or permission needs, but for a simple preview tool this is acceptable.
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 two sentences, front-loaded with the primary action, and every sentence earns its place: the first gives the core behavior, the second explains the optional copy and intended use case.
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 tool with two parameters, an output schema, and behavioral annotations, the description covers purpose, usage context, and side effects. The return format is handled by the output schema, so no further detail is needed.
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?
With 50% schema coverage, the description helps fill gaps. It clarifies that templateId is the 'selected candidate' and that destination enables a local copy for view_image. The schema alone leaves templateId's role ambiguous, so the description adds meaningful semantic 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 opens with a specific action: 'Return the selected candidate preview as standard MCP image content.' It names the resource (candidate preview) and distinguishes the tool from siblings by focusing on visual auditing before final recommendation.
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 states when to use: 'Use this to visually audit the top retrieval candidate before making a final recommendation.' It also mentions a follow-up path (copying for Wisp Agent to call view_image), but it does not explicitly contrast with sibling tools like figure_library_open or figure_library_materialize.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description discloses that the tool 'never executes code or stores original absolute paths' and that Transfer Packages enter as 'draft visual references.' These are meaningful safety and behavioral details not present in annotations or schema, and they do not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, every one earning its place: the action, the key safety behavior, and the migration guidance. It is front-loaded and contains no filler.
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 16-parameter tool with output schema and annotations, the description covers the essential modes, import result state, safety properties, and alternative tool selection. Parameter details are appropriately left to the schema, especially since key path parameters already have schema descriptions and an output schema exists.
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 only 25%, and the description does not compensate by explaining the 16 parameters. It references 'figure/code' and 'ZIP', which maps to codePaths/packagePath, and mentions draft visual references, but most optional metadata parameters such as tags, title, license, reviewStatus, and assetKind are left entirely to schema 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 opens with specific actions: 'Copy a user-supplied figure/code or validate and import a Figure Transfer Package ZIP.' It clearly names two distinct input modes, uses specific verb-resource pairs, and differentiates itself from siblings by flagging direct-write as legacy versus the plan/apply alternatives.
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 states that new Agents should use figure_library_plan_import and figure_library_apply_import instead, giving clear when-not-to-use guidance and naming alternatives. This is a model example of usage differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral context beyond the annotations: 'atomically replace' indicates atomicity, 'one stable snapshot' limits scope, and 'Code is copied but never executed' is a critical safety disclosure. These traits are not present in the annotations, and the description does not contradict them.
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 two sentences long, front-loaded with the primary purpose, followed by usage guidance and a critical safety note. Every sentence contributes meaning, with no repetition or filler.
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?
With an output schema present and annotations covering idempotency and safety, the description provides the essential purpose, usage context, and a key behavioral note. It does not elaborate on failure modes or replacement semantics, but these are largely covered by the structured fields.
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 provides no descriptions (0% coverage), so the description must compensate. It mentions the concepts of Gallery/Transfer Package and snapshot, giving some context for galleryPath and packagePath, and sourceCommit is implied. However, it does not explicitly explain each parameter's role or format, leaving room for ambiguity.
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: 'Validate and create or atomically replace one stable Gallery/Transfer Package snapshot.' It includes a specific verb (upsert), resource (Gallery/Transfer Package snapshot), and distinguishes itself by referencing figure_library_diff for content changes. The additional note that 'Code is copied but never executed' further clarifies the tool's role.
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 instructs 'Use figure_library_diff first when content changed,' naming an alternative tool and the condition under which it should be used instead. This provides clear guidance on when this upsert tool is appropriate, distinguishing it from related sibling tools.
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:

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

Score Badge

Copy to your README.md:

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

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/xuzhougeng/ScientificFigureLibrary'

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