metabo-idmapper

by Wooyoung-kim91

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.0.1
Disambiguation5/5
Each tool targets a distinct step in the metabolomics ID mapping workflow, from ingestion and matching to verification, decision recording, and reporting. Descriptions are detailed and clearly differentiate overlapping functions like exact_match vs search_synonym or bridge_xref vs backfill_hmdb.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern in snake_case (e.g., structure_lookup, ingest_names, exact_match). No mixing of conventions or vague verbs.
Tool Count4/5
20 tools is on the higher end but justified by the complex multi-stage pipeline. Each tool has a clear role, and the count supports the full workflow without unnecessary redundancy.
Completeness5/5
The tool set covers the entire metabolomics ID mapping process: input handling, matching, verification, exclusion, decision recording, cross-referencing, report generation, and audit. No obvious gaps are present.
Average 3.5/5 across 20 of 20 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 10 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description must disclose behavior. 'Report' and 'suggest' imply read-only, but no details on side effects, permissions, or limitations.
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?
Single sentence is concise, but brevity sacrifices necessary details; it is not a model of efficient communication.
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 no output schema, no annotations, and one parameter, the description fails to define 'mapped vs pending', output format, or how suggestions work.
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 coverage is 0% (no parameter descriptions), and the description does not clarify the 'workdir' parameter or how it influences results.
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 reports mapping status and suggests next tools, distinguishing it from specific action siblings like plot_coverage or ingest_names.
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 on when to use versus alternatives. The implied usage from the description is vague without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states output files but does not disclose whether the tool is read-only, destructive, requires authentication, or how it behaves in failure cases. The implied behavior is generating static files, which is minimally transparent.
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 concise, using a single sentence to convey output file paths. However, it lacks a clear action verb and is structured as a list rather than a coherent directive. It could be improved by front-loading a verb and clarifying the scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter and no annotations or output schema, the description fails to explain the context of the figures, required inputs (workdir), or when to invoke it. It only names output files, leaving significant gaps for the agent to understand proper usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'workdir' has 0% schema description coverage, and the tool's description does not explain its purpose or format. The parameter is self-explanatory in name, but the description adds no additional meaning, leaving the agent to infer usage.
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 that the tool generates two specific figures related to DB matching, providing clear resource identification. However, it lacks a direct verb (e.g., 'generates' or 'plots'), relying on implicit meaning from 'figures'. It does not differentiate among siblings, but the tool name and context are distinct enough.
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 says 'Always-on' which implies it is intended for routine use, but it gives no explicit guidance on when to use this tool versus alternatives or prerequisites. No exclusion criteria or context for optimal use is provided.
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 supplied, so the description must fully convey behavioral traits. It states the output fields and mentions evidence attachment, but it omits details on side effects, authentication needs, rate limits, or whether modifications occur. The description is too minimal to fully inform an agent.
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 conveys the core purpose efficiently. However, it could benefit from being more structured (e.g., listing parameters) without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, 3 parameters with 0% schema coverage, and many sibling tools, the description is severely incomplete. It fails to explain the required parameters, output format, or how it differs from related tools like 'search_synonym' or 'exact_match'.
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 coverage is 0%, so the description must explain parameters. It only mentions 'name' as input, but the schema includes two required parameters ('workdir' and 'feature_id') with no explanation. This leaves the agent unsure how to use those required parameters, making the description insufficient.
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 a PubChem lookup of chemical names to identifiers (CID, InChIKey, formula, monoisotopic mass) and attaches evidence. The verb and resource are clear, but it does not explicitly distinguish from siblings like 'search_synonym' or 'exact_match' which might also perform lookups.
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 prerequisites, contraindications, or alternative tools for different scenarios (e.g., searching by other identifiers).
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 conveys that the tool writes multiple files and always emits figures and enriched_xref.tsv when figures=True. However, it does not disclose potential side effects like file overwriting or required permissions. Adequate but not comprehensive.
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?
Two sentences front-load the main action and key default behavior. Efficient, but could be slightly restructured to separate primary action from optional outputs.
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 3 parameters and no output schema, the description covers the primary outputs (TSVs, figures) but lacks details on file content, format, or what the figures represent. Adequate for a tool with simple parameters but incomplete for a tool that writes multiple outputs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must explain parameters. It mentions 'optionally write' (likely controlled by 'export') and 'figures=True' triggers files, but does not explain 'workdir' or the exact behavior of 'export'. Leaves significant ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool computes class/confidence coverage and writes multiple TSV files, with figures when figures=True. It provides specific verb and resource, but does not explicitly differentiate from sibling 'plot_coverage' though the file-writing aspect distinguishes it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., plot_coverage). No prerequisites or context provided. The description only states what it does, not when to use it.
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 must fully disclose behavior. It describes the appending action, that the original file's columns are kept, and that outputs are written to the workdir. However, it does not explicitly state that the original file is not modified, and it lacks details on permissions, rate limits, or potential side effects. The description adds some context but could be more thorough.
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 reasonably concise, with the primary action front-loaded in the first sentence. The second paragraph adds key parameter details without redundancy. While some information is repeated between schema and description, the text is efficient and clear.
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 6 parameters, 0% schema coverage, no output schema, and no annotations, the description covers the core workflow but misses some parameter meanings (out, sheet, name_column). It explains output files and columns added, but lacks details on return values or side effects. It is adequate but not fully complete for a complex tool.
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 0%, so the description must explain parameters. It explains 'source' (defaulting to ingest_names record) and 'header' (0-based row index for preamble), but does not cover 'out', 'sheet', or 'name_column'. This leaves 3 out of 6 parameters undocumented in the description, providing only partial compensation for the schema gap.
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 appends ID columns to the original data file and lists the specific columns added. It explains the matching by compound name and outputs. However, it does not differentiate from sibling tools like exact_match or verify_candidate, leaving some ambiguity about when to use this tool over others.
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 minimal guidance on when to use this tool. It mentions that if 'source' is omitted, it uses the source recorded by ingest_names, and explains the header parameter. But there is no explicit instruction on when to use this tool versus alternatives, nor any exclusions or prerequisites.
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 discloses key behaviors: exact matches are committed at confidence M1, non-exact items remain pending, and auto_accept_exact controls automatic acceptance. This adds good context beyond a basic purpose statement.
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?
Two sentences front-load purpose and then detail behavior. No wasted words, though the structure could be enhanced with a brief note on parameters.
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?
Lacking output schema, the description does not mention what the tool returns. It also fails to explain two of three parameters. For a batch lookup tool with moderate complexity, more detail is needed to be fully self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It explains the auto_accept_exact parameter's effect but does not explain workdir (required) or feature_ids (optional). Only one of three parameters gains clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it performs exact name-to-ID matching in MetaboAnalyst, distinguishing it from a 'judgement'. However, it does not explicitly differentiate from sibling tools like search_synonym or verify_candidate, though the exact-match focus is implied.
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?
Implies usage for exact DB-name matches only, and that non-exact items stay pending for the LLM. Provides some guidance on the auto_accept_exact flag but does not explicitly state when not to use the tool or name alternatives.
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 present, so the description bears full responsibility for behavioral disclosure. It clearly states that the tool writes multiple TSV files, indicating a write operation. However, it does not mention permissions, reversibility, or side effects beyond file creation, which is acceptable given the file-writing nature.
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, dense sentence that packs several key points (provenance, logic, unmapped, origin buckets) but becomes somewhat run-on. It could be more concise by splitting into bullet points or separate sentences for readability without losing content.
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 complexity of the tool (multiple output files, detailed logic), the description provides a thorough overview of what is produced and the concept of provenance. However, it omits parameter explanations, which reduces completeness slightly. With no output schema, listing output files is valuable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, meaning the description does not explain the parameters 'export' and 'workdir'. The description focuses entirely on outputs and logic, leaving parameter semantics undefined. This forces agents to rely solely on the schema, which lacks descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: recovering provenance for KEGG/HMDB mappings beyond the initial pass, detailing logic, unmapped entries, and origin buckets. It lists specific output files, making the purpose concrete and distinct from sibling tools, which likely handle other aspects of metabolomics analysis.
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 lacks explicit guidance on when to use this tool versus alternatives. It does not mention prerequisites, conditions, or when not to use it. The context is implied by the description but no direct usage recommendations are provided.
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 provided, so description carries full burden. Attributes like 'deterministic' and 'gate' give some behavioral hints, but it does not describe what happens on failure (e.g., returns boolean vs throws), side effects beyond optional logging, or any authorization or prerequisite requirements.
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. The first delivers the core purpose; the second adds optional behavior. No fluff.
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 8 parameters, no output schema, and no annotations, the description is insufficient. It lacks parameter semantics, failure modes, return format, and data flow context. An agent would struggle to invoke this tool correctly without additional knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and no parameter details are provided in the description. The 8 optional parameters (workdir, rationale, feature_id, mass_tol_ppm, observed_mass, proposed_mass, observed_formula, proposed_formula) have no explanatory text, leaving agents without guidance on how to use them.
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 states it is a deterministic formula/mass consistency gate required before accepting fuzzy/synonym/mass-only candidates. The verb 'verify' and resource 'candidate' combined with the gate context distinguish it from sibling tools like exact_match, search_synonym, mass_match_candidates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states it is required before accepting any fuzzy/synonym/mass-only candidate, providing clear use context. Mentions optional logging to ledger. Does not explicitly say when not to use or name alternatives, but the sibling list and gate role imply proper usage.
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 full burden. It mentions batch processing, one-time DB load, and side effect of attaching candidates when feature_id and workdir are provided. However, it omits error conditions, performance, or what happens without feature_id.
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 concise with key points front-loaded. It uses bullet-like structure for query format, but could be slightly more organized. No extra verbiage.
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?
For a tool with 3 params, no output schema, and no annotations, the description covers the main use case but lacks details on return values, error handling, and limitations. It's adequate but not comprehensive.
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 description must compensate. It explains the 'queries' parameter structure and valid source/target values, and ties 'workdir' to condition. But the 'db' parameter is entirely undocumented, leaving a gap.
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 promotes IDs across systems using BridgeDb in batch mode, which is a specific verb-resource pairing. This distinguishes it from siblings like structure_lookup or exact_match by focusing on cross-referencing IDs.
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 on when to use this tool versus alternatives among 19 siblings. The description implies use for batch ID mapping across specific databases, but lacks when-not-tos or comparisons.
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 burden. It discloses the tool returns candidates and the LLM must pick and verify, signaling it is read-only and non-committal. However, it omits details about error behavior, rate limits, or whether it modifies any state.
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 concise sentences, front-loaded with the core action (search databases for query strings) and immediately followed by critical behavioral notes (returns candidates, never auto-accepts). No wasted words.
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?
While the purpose is clear, the description lacks details about parameters and output format. With 5 parameters, no output schema, and no annotations, the agent is insufficiently equipped to use the tool correctly without external knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides no information about the five parameters (workdir, feature_id, queries, dbs, max_per_term). Schema coverage is 0%, so the agent has no guidance on how to set these fields, risking incorrect usage.
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 searches KEGG, PubChem, and ChEBI for query strings like abbreviation expansions, typo fixes, and synonyms. It distinguishes itself from siblings like exact_match by emphasizing it returns candidates and the LLM must pick and verify.
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 specifies the tool is for LLM-proposed query strings (abbrev expansions, typo fixes, synonyms) and that it never auto-accepts, implying a manual verification step. However, it does not explicitly mention when not to use it or point to alternative tools.
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 burden. It mentions it reads specific files and requires Python packages, providing some behavioral context. However, it lacks details on whether the tool modifies files, error handling, or read-only status.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences, well-structured, and front-loaded with the main action. It lists sections efficiently without extraneous detail.
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 2 parameters, no output schema, and sibling tools, the description provides adequate context about the tool's purpose and prerequisites but lacks detail on parameters and output format, leaving some 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?
The input schema has 0% description coverage, and the description does not explain the parameters 'out' or 'workdir'. It does not link the mentioned input files to 'workdir', nor does it clarify the 'out' parameter.
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 builds a PPTX report from run outputs and figures, listing specific sections like 'Title', 'Coverage KPI', 'Methods', etc. This distinguishes it from sibling tools such as plot_coverage or export_code.
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 explicit prerequisites: 'run coverage_summary first' and 'Requires python-pptx + pillow'. It implies when to use (after coverage_summary has been run) but does not explicitly state when not to use or mention alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool sets 'gem_mam' and 'gem_cause' fields and explains the 'id-gap' condition. However, with no annotations, it omits other behavioral traits such as auth needs, rate limits, or side effects. The core behavior is clarified but not fully transparent.
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, zero waste. The first sentence front-loads the primary purpose, the second adds a key behavioral detail. 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 core mapping logic and field setting are explained, but given the absence of output schema and annotations, the description lacks details on return values, prerequisites (e.g., model_path), and side effects. For a state-setting tool, more completion is needed.
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%, and the description vaguely hints that 'feature_ids' are the IDs to map but does not explain 'workdir' or 'model_path'. This provides minimal additional meaning beyond the raw schema, failing to compensate for the lack of schema descriptions.
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 maps KEGG/HMDB/ChEBI IDs to Mouse-GEM MAM species for flux input, using a specific verb ('Map') and resource ('accepted...ids to Mouse-GEM MAM species'). This distinguishes it from sibling tools like bridge_xref or exact_match, which likely handle different mapping scenarios.
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 flux input mapping from specific databases, but lacks explicit guidance on when to avoid this tool or prefer alternatives like bridge_xref. No exclusion criteria or context are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions normalization, ledger seeding, and flags for LLM attention (parenthetical abbreviations, combined names, isomer-sensitive digit locants). However, without annotations, it lacks details on destructive potential, permissions, side effects, or reversibility. Partial disclosure.
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: first sentence states core purpose concisely; second sentence adds critical behavioral nuance without redundancy. 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?
Given 5 parameters, no output schema, and no annotations, the description covers input methods and a behavioral flag but omits details on return value, error cases, normalization specifics, and ledger semantics. Adequate but incomplete.
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 description adds meaning to parameters by explaining that input can be a list (names parameter) or an xlsx column (xlsx, sheet, column). This compensates for 0% schema coverage. However, the workdir parameter is not explained.
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: 'Load raw names (list OR an xlsx column), normalize, and seed the ledger.' It specifies the input sources and the processing pipeline, distinguishing it from sibling tools that perform different tasks like structure_lookup or exact_match.
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 on when to use this tool versus alternatives. The description does not mention exclusions, prerequisites, or context for selection. The agent must infer usage from the tool purpose alone.
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 must carry the full burden. It discloses the core behavior (setting fields based on origin logic) and provides detailed rules. However, it omits important operational details such as idempotency, error states, required permissions, or what the function returns, limiting transparency.
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 somewhat verbose and dense, mixing core purpose with detailed conditional logic. It is front-loaded with the main verb and resource, but the length and lack of structure (e.g., bullet points) reduce readability. Every sentence earns its place, but brevity could improve.
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 tool's complexity (7 parameters, no output schema, no annotations), the description covers the essential decision logic but fails to address the return value, error scenarios, or additional side effects. It is adequate for a focused agent but not fully 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 0%, so the description must compensate. It explains 'origin' and 'final_class' in detail, adding significant meaning. However, other parameters like 'workdir', 'accepted', 'rationale', and 'confidence' are not described, leaving gaps that the schema (only types) does not fill.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Commit the LLM's identity CALL for one entry — the ONLY tool that sets final_class/confidence/origin.' It uses a specific verb ('Commit') and explicitly distinguishes itself from sibling tools as the sole tool for this critical action.
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 when to use it (to commit a decision for an entry) and explicitly states it is the only tool for setting these fields, providing context. However, it lacks explicit guidance on when not to use it or prerequisites (e.g., feature must be identified first), which keeps it from a 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?
No annotations are provided, so the description carries the full burden. It details the output: two code files with specific formats. It does not mention side effects, permissions, or rate limits, but as an export tool, it is likely non-destructive and does not modify state. The description provides sufficient behavioral context for safe invocation.
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 paragraph but is well-structured, starting with the main action. It is detailed yet efficient, with no redundant sentences. However, it could be broken into shorter sentences for easier parsing.
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 only one parameter and no output schema, the description adequately covers the tool's purpose and output. It explains what files are generated and their format. It could mention prerequisites like a completed run or required directories, but overall it is sufficiently complete for an export tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter, 'workdir', is in the schema with no description (0% coverage). The tool description does not explain what 'workdir' represents or its expected format. With low schema coverage, the description should compensate but fails to add meaning beyond the parameter name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: writing standalone reproduction code using original library APIs. It specifies the verb 'write', the resource 'reproduction code', and details the libraries and output files. It distinguishes from sibling tools by focusing on code export rather than data lookup or plotting.
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 does not explicitly state when to use this tool versus alternatives. It implies usage after a run for reproducibility, but lacks explicit 'when to use' or 'when not to use' guidance. Sibling tool names suggest other functions, but no comparative advice is given.
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 provided, the description bears full burden for behavioral transparency. It discloses that the operation is a single batched call, adds HMDB as an extra xref, does not modify KEGG assignments, and converts structure-only entries to HMDB-mapped. It does not cover potential side effects like rate limits, but the given details are sufficient for usage.
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 moderately concise and packs relevant information in two sentences. The first sentence is lengthy but captures the core functionality. The second provides context without redundancy. Slightly more brevity could be achieved, but it remains efficient.
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 no output schema and a batch operation, the description explains the tool's effect and constraints well. However, it omits parameter semantics and does not specify the return value or confirmation. An agent would need to infer workdir from context. The description is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no descriptions (0% coverage) and the description does not explain the two parameters ('db' and 'workdir'). The description mentions IDs used (InChIKey/KEGG/ChEBI/PubChem) but does not map these to parameters or clarify their values. This is a severe gap; an agent cannot determine what to provide for 'db' or 'workdir'.
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: bridging missing HMDB for entries lacking an accepted HMDB via BridgeDb in one batched call. It specifies the resource (HMDB), the verb (backfill/bridge), and the scope (non-excluded entries). It distinguishes from sibling tools like bridge_xref by focusing specifically on HMDB backfill.
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 provides explicit guidance on when to use the tool, including the motivation (run-2 finding about under-counted HMDB) and what it does not affect (KEGG assignments, final_class/origin of KEGG-mapped entries). It also states that xenobiotic-excluded entries are skipped, clarifying boundaries.
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 should convey behavioral traits. It mentions 'weak evidence' indicating the tentative nature of the output, but does not disclose other behaviors such as whether it is read-only, requires authentication, or has rate limits. The description is minimal but not misleading.
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 clearly state the transformation and usage guidance with no superfluous words. The key information is front-loaded.
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 tool with 3 parameters and no output schema, the description covers the core purpose and usage. However, it omits details about the output (e.g., return format, windows) and how tolerance influences the result, which a user might need for proper invocation. Still, it is complete enough for its simple role.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains the roles of m/z and adduct (to compute mass windows) but does not explain the 'tol_ppm' parameter or the format of 'adducts' (e.g., strings). Schema coverage is 0%, so more detail is needed to compensate, but the description only partially covers the parameters.
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 transformation (m/z + adduct -> neutral monoisotopic mass windows) and labels it as weak evidence. It distinguishes from siblings by specifying that the result should be handed to search_synonym or a DB search, making the tool's role unambiguous.
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?
Explicitly states when to use this tool (to generate mass windows) and when not to rely on it ('never accept a mass-only hit as primary'), also directing to siblings (search_synonym, DB search). This provides clear usage guidelines.
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 must carry the burden. It indicates the tool returns workflow and rules, but does not disclose any side effects, authentication requirements, or expected behavior on repeated calls.
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 short, front-loaded sentences with zero wasted words. Every phrase 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?
With no output schema, the description should explain the return format or content more precisely. 'Canonical workflow + operating rules' is vague and leaves the agent guessing what exactly it receives.
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 and schema coverage is 100%, so the baseline is 4. The description adds nothing extra about parameters, which is appropriate since there are none.
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 ('Return') and resource ('canonical workflow + operating rules'), and clearly distinguishes from sibling tools by indicating it's a one-time startup call.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'Call once at the start,' providing clear timing. Does not mention alternatives, but for a setup tool this is sufficient.
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?
No annotations provided, so description carries full burden. It discloses deterministic behavior, EMITS evidence only, and explains the exclusion logic for biologically exogenous compounds. It also describes the output (surfaces xenobiotic-class names) and its purpose for reclassification.
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 informative but slightly lengthy. It is well-structured and front-loaded with the key purpose. Could be slightly more concise, but every sentence adds value.
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 has one parameter and no output schema, the description covers the main behavioral aspects and purpose. It does not describe return format or how to use results, but it is fairly complete for a screening tool. The missing param documentation is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter (workdir) with 0% schema description coverage. The tool description does not mention the workdir parameter at all, leaving the agent without guidance on what value to provide. While workdir is self-explanatory, the lack of documentation is a gap.
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 explicitly states it screens for xenobiotics (non-biological) using LC-MS additives, surfactants, etc., and distinguishes from biologically exogenous compounds. It clearly defines the scope and differentiates from the broader 'exogenous' class. The verb 'screen' and specific resource 'xenobiotic' are clear.
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?
Description explains when to use (for xenobiotic detection) and when not (for biologically exogenous compounds, which require reasoning). It mentions that the driver can reclassify surfaced names. This provides clear context for tool selection.
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?
No annotations exist, so the description carries full burden. It declares itself read-only ('changes nothing, read-only') and lists all specific checks performed, as well as the output format (pass/warn/fail scorecard). This fully discloses behavior.
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 dense paragraph, front-loaded with purpose. It is slightly verbose due to listing many checks, but every sentence adds value. Could be restructured with bullet points for clarity, but remains effective.
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 complexity (many checks), no output schema, and low schema coverage, the description is complete: it specifies all checks, output format, read-only nature, and order of execution. No gaps remain for an agent to invoke correctly.
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 0% schema coverage and only one required parameter ('workdir'), the description adds context by mentioning 'reads the session ledger + workdir artifacts', implying workdir is the directory containing these artifacts. This compensates for the lack of schema 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 explicitly states it is a governance/process-completeness auditor that reads session ledger and workdir artifacts to check multiple specific conditions. It clearly distinguishes from siblings by noting it should run last after coverage_summary.
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 explicit timing: 'Run LAST (after coverage_summary).' It does not include when-not-to-use examples, but the clear placement in the workflow suffices.
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:

[![metabo-idmapper MCP server](https://glama.ai/mcp/servers/Wooyoung-kim91/metabo-idmapper/badges/card.svg)](https://glama.ai/mcp/servers/Wooyoung-kim91/metabo-idmapper)

Score Badge

Copy to your README.md:

[![metabo-idmapper MCP server](https://glama.ai/mcp/servers/Wooyoung-kim91/metabo-idmapper/badges/score.svg)](https://glama.ai/mcp/servers/Wooyoung-kim91/metabo-idmapper)

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/Wooyoung-kim91/metabo-idmapper'

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