tomesphere
Server Details
Search 8.5M scientific papers with LLM TLDRs, citations, linked entities, figures, and full text.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.2/5 across 9 of 9 tools scored.
Each tool has a clearly distinct purpose: citation retrieval is split into inbound and outbound, paper data is divided into metadata, full text, figures, entities, and structure, with separate search and similarity tools. No overlap.
Most tools use snake_case, but there's a mix of 'get_' prefix (get_entities, get_figures, etc.) and direct action names (citations, references, search_papers). This is minor inconsistency; overall pattern is clear.
9 tools is well within the optimal range for a scientific paper server. Each tool adds unique value without overwhelming the interface.
The server covers the full lifecycle for paper retrieval: search, metadata, full text, figures, citations (both directions), entities, structure, and similarity. No obvious gaps for its read-only purpose.
Available Tools
9 toolscitationsARead-onlyInspect
Get papers that cite the given paper (who refers to this work). Use when the user asks 'who cites X', 'what's the impact', or wants follow-up work. Note: 2024+ citation coverage is sparse; indexing in progress.
| Name | Required | Description | Default |
|---|---|---|---|
| k | No | Max citing papers (default 25, max 100). | |
| id | Yes | arXiv ID or OpenAlex Work ID. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds a key behavioral limitation (sparse 2024+ coverage) beyond what annotations (readOnlyHint, openWorldHint) provide. No contradictions 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no waste. Purpose, usage, and limitation are front-loaded. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given schema coverage (100%) and annotations (readOnlyHint, openWorldHint), the description is complete. It explains purpose, usage, and a key limitation. No output schema needed for a list-of-papers tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. Description adds no additional parameter details beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Get papers that cite the given paper' with specific verb+resource. Distinguishes from siblings like references (inverse) and similar_papers (similarity, not citations).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit usage examples ('who cites X', 'what's the impact', 'follow-up work') are provided. Missing explicit when-not usage, but the context is clear. A note about sparse 2024+ coverage adds important caveat.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_entitiesARead-onlyInspect
Get the biomedical entities linked to a paper: genes, proteins, chemicals, diseases, species, mutations, cell lines, and clinical-trial (NCT) IDs. Accepts an arXiv ID, PMC ID, or bioRxiv/medRxiv DOI.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | arXiv ID, PMC ID, or 10.1101/… DOI. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint and openWorldHint. The description enhances transparency by detailing which entity types are returned and which ID formats are accepted. It does not contradict annotations or introduce new behavioral concerns (e.g., pagination or rate limits).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first defines the purpose and output, the second specifies acceptable inputs. It is concise, front-loaded, and contains no superfluous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool structure (one parameter, no output schema, clear annotations), the description adequately covers what the tool does and what inputs it accepts. It does not discuss pagination or response format, but openWorldHint implies variability. Overall, it is sufficient 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter 'id' is fully described in the schema (100% coverage). The description echoes this information without adding new semantic details. Thus, it meets the baseline for a well-documented parameter but does not exceed it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves biomedical entities linked to a paper, enumerating specific entity types (genes, proteins, etc.) and accepted ID formats. This distinguishes it from sibling tools like get_paper (returns paper metadata) or get_figures (returns figures).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by specifying the input types and listing entity categories. However, it does not explicitly state when not to use it or direct to alternatives for different tasks (e.g., paper metadata vs. entities). The context is clear but lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_figuresARead-onlyInspect
Get a paper's real figure images — URLs, labels, and captions. Most biomedical papers have figures; arXiv papers often don't. Accepts an arXiv ID, PMC ID, or bioRxiv/medRxiv DOI.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | arXiv ID, PMC ID, or 10.1101/… DOI. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond the readOnlyHint and openWorldHint annotations by specifying the exact output fields (URLs, labels, captions) and noting the variability in figure availability between biomedical and arXiv papers. This enriches the agent's understanding of expected results.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences. The first sentence states the purpose and output, while the second provides essential context on identifier types and figure availability. Every word adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description mentions the output includes URLs, labels, and captions, but does not specify the return structure (e.g., array of objects) or behavior for papers without figures. Given the lack of an output schema, slightly more detail on format would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes the 'id' parameter with examples, and the tool description restates these types, adding specificity for bioRxiv/medRxiv. With 100% schema coverage, the description adds marginal value, resulting in a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a paper's figure images, specifying the output includes URLs, labels, and captions. It distinguishes from sibling tools by focusing on visual content and explicitly lists supported identifiers (arXiv ID, PMC ID, bioRxiv/medRxiv DOI).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when figure images are needed and provides a caveat about arXiv papers often lacking figures. However, it does not explicitly compare to sibling tools like get_full_text or get_paper, nor does it offer guidance on when to use this tool instead of alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_full_textARead-onlyInspect
Fetch a paper's full body text as Markdown (methods, results, protocols, inline tables) — use for deep questions the abstract can't answer. Accepts an arXiv ID (2401.12345), a PMC ID (PMC5339222), or a bioRxiv/medRxiv DOI (10.1101/…).
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | arXiv ID, PMC ID, or 10.1101/… DOI. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and openWorldHint=true. The description adds value by specifying the return format (Markdown) and content scope, but does not discuss additional behaviors such as rate limits, error handling, or typical response size. No contradictions 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two concise sentences: the first states purpose and usage context, the second details acceptable identifiers. Every word is informative with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of an output schema, the description covers the tool's core function and input format well. However, it omits details about behavior when full text is unavailable, length limits, or whether the response always includes all mentioned sections. It is adequate but could be slightly more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a simple description. The description adds significant meaning by specifying the three accepted ID formats (arXiv, PMC, bioRxiv/medRxiv DOI) and providing concrete examples, greatly aiding the agent in constructing valid invocations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Fetch', the resource 'paper's full body text', the format 'Markdown', and the content types included (methods, results, protocols, inline tables). It also distinguishes from abstracts by specifying 'use for deep questions the abstract can't answer', effectively differentiating from siblings like 'get_paper'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly recommends use for questions beyond abstracts, and lists accepted ID formats with examples. It does not provide explicit exclusions or name alternative tools, but the context of sibling tools and the positive guidance are strong enough for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_paperARead-onlyInspect
Fetch a paper's full metadata: title, authors, year, abstract, TLDR (LLM-generated), key findings, citation count, GitHub repos, HuggingFace models/datasets, videos, peer reviews, and links. Accepts an arXiv ID (e.g. '2401.12345' or '1706.03762v5') or an OpenAlex Work ID (e.g. 'W4390723197'). Use when the user names a specific paper or pastes an arXiv link.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | arXiv ID like '2401.12345' or OpenAlex Work ID like 'W4390723197'. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint. The description adds a comprehensive list of returned fields, which is useful. No contradictions. However, no mention of error handling or response size limits, but acceptable for a fetch tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence but well-structured with a list of returned fields and ID formats. Concise and informative, though could benefit from slight formatting for readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given one parameter, no output schema, and sibling tools, the description is complete: it specifies what it returns, accepted IDs, and usage. Minor missing details like output format are not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. The description adds examples of arXiv ID format and mentions OpenAlex Work ID, providing useful context beyond the schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states it fetches full metadata of a paper and lists specific fields (title, authors, year, abstract, etc.). It distinguishes from siblings like search_papers or references by focusing on a specific paper via ID.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description clearly states when to use: 'when the user names a specific paper or pastes an arXiv link.' It does not explicitly exclude other cases, but the context is clear. Could mention alternatives like search_papers for ambiguous requests.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_structureARead-onlyInspect
Resolve a gene/protein name (e.g. 'TP53', 'CD44') or UniProt accession to its 3D structure — returns the UniProt accession + AlphaFold model URL (and PDB when available). Great for a gene named in a paper's entities.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Gene/protein symbol (TP53, CD44) or UniProt accession (P04637). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and openWorldHint=true. The description adds that it returns specific data (UniProt accession, URLs) but doesn't disclose potential API dependencies or error scenarios, which is acceptable for a simple read tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: the first defining function and output, the second suggesting use case. No wasted words, information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Though no output schema, the description explains what is returned. It could detail how to use the URLs, but for a one-parameter tool this is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'name' is fully described in the schema with examples. The tool description adds minimal extra meaning beyond saying it's 'Great for a gene named in a paper's entities', so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool resolves a gene/protein name to its 3D structure, specifying the return of UniProt accession and URLs. It distinguishes from sibling tools like get_entities or get_paper by focusing on structure retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The note 'Great for a gene named in a paper's entities' provides context for when to use, but lacks explicit when-not or alternatives. Given sibling diversity, the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
referencesARead-onlyInspect
Get the papers that this paper cites (its bibliography). Use when the user asks 'what does X cite' or 'show me the references'.
| Name | Required | Description | Default |
|---|---|---|---|
| k | No | Max references (default 25, max 100). | |
| id | Yes | arXiv ID or OpenAlex Work ID. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds no additional behavioral context beyond what annotations provide, but it does not contradict them. It is consistent 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first sentence states core purpose, second sentence gives usage examples. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, good annotations, and complete schema, the description is sufficient. It covers purpose and usage. Without an output schema, a hint about return format could add value, but not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for both parameters (k and id). The description does not add new parameter-specific context beyond the schema. Baseline is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves bibliography entries for a given paper using the verb 'get' and resource 'papers that this paper cites'. It also provides usage examples distinguishing it from sibling tools like 'citations'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly gives when-to-use scenarios (e.g., 'what does X cite'). While it does not list negative conditions or alternatives, the examples imply when not to use (e.g., not for citations).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_papersARead-onlyInspect
Search 8.5 million academic papers (arXiv + biomedical: PMC / bioRxiv / medRxiv, all disciplines) by topic, keyword, author, or linked entity (gene / protein / disease). Each hit returns id, title, TLDR, type, and links. Use to find papers about a topic, e.g. 'transformer efficiency' or 'CRISPR base editing'.
| Name | Required | Description | Default |
|---|---|---|---|
| k | No | Number of results (default 10, max 25). | |
| query | Yes | Natural-language search query. E.g. 'transformer attention efficiency', 'graph neural networks for molecular property prediction'. | |
| year_max | No | Latest publication year. | |
| year_min | No | Earliest publication year, e.g. 2024. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint and openWorldHint, and description adds context: searches 8.5M papers from specific repositories, returns structured results. No contradictions; adds behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, clear and front-loaded with key information (scope, sources, result fields, usage examples). No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given good annotations, full schema coverage, and no output schema, the description provides sufficient context for a search tool. It explains sources, query types, and result fields comprehensively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All parameters have descriptions in input schema (100% coverage). Description adds context about natural-language search and entity linking but does not significantly extend beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it searches 8.5 million academic papers from specific sources (arXiv, PMC, bioRxiv, medRxiv) by topic, keyword, author, or linked entity, and returns id, title, TLDR, type, links. It distinguishes from siblings like get_paper, similar_papers by focusing on search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description gives concrete examples of when to use ('find papers about a topic') and what results look like, but does not explicitly state when not to use or mention alternatives among the sibling tools (e.g., citations, references).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
similar_papersARead-onlyInspect
Find papers semantically similar to a given paper using SPECTER2 embeddings (trained on scientific-citation triplets). Returns nearest neighbors with TLDR. Use when the user wants 'papers like X' or 'what's adjacent to this work'.
| Name | Required | Description | Default |
|---|---|---|---|
| k | No | Number of neighbors (default 10, max 25). | |
| id | Yes | arXiv ID or OpenAlex Work ID. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and openWorldHint. The description adds behavioral detail: it uses SPECTER2 embeddings and returns nearest neighbors with TLDR, which goes beyond the annotations. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states functionality and method, second gives usage guidance. No unnecessary words, front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately explains that it 'returns nearest neighbors with TLDR'. Combined with schema and annotations, the tool's behavior is fully specified for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and both parameters are described in schema. The description does not add additional meaning beyond the schema, so it meets the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Find papers semantically similar to a given paper' using a specific method (SPECTER2), and the tool's purpose is distinct from siblings like citations or references. It provides a clear verb-resource pair and differentiates from other tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use when the user wants "papers like X" or "what's adjacent to this work"', providing clear usage context. While it doesn't explicitly state when not to use it, the sibling tools list gives alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!