Repository evidence for agents before they adopt dependencies, enter codebases, compare, or merge.
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.
Average 4.4/5 across 5 of 5 tools scored.
Each tool has a clearly distinct trigger and outcome: analyze_repo gives a brief overview, get_artifact returns the full artifact, check_change_risk assesses PR/diff risk, check_dependency evaluates a single dependency, and compare_repos compares two. No two tools could be easily confused.
All tool names follow the consistent verb_noun pattern in snake_case (analyze_repo, check_change_risk, check_dependency, compare_repos, get_artifact). This makes the tool surface predictable and easy to navigate.
With only 5 tools, the set is tightly scoped to the server's decision-support purpose. Each tool covers a distinct analytical need without redundancy or bloat.
The tool surface covers the main repo evaluation workflows: understanding a repo, accessing deep context, assessing change risk, vetting dependencies, and comparing alternatives. No obvious gaps for the stated purpose.
analyze_repoGet a repository decision briefACALL when entering an unfamiliar repository or deciding whether to depend on, fork, learn from, or deploy it. Returns a concise four-use-case brief, watchouts, evidence confidence, architecture summary, freshness, and next actions without dumping the full generated artifact. Use get_artifact when file-level orientation is needed. Pass exactly one of repo or package.
| Name | Required | Description | Default |
|---|---|---|---|
| repo | No | Public GitHub repository as owner/repo or a github.com URL. | |
| package | No | npm package name, for example lodash or npm:@scope/pkg. |
| Name | Required | Description |
|---|---|---|
| tool | Yes | |
| agent | Yes | |
| status | Yes | |
| schema_version | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only/idempotent, and the description adds behavioral detail: it returns a concise brief with watchouts, evidence confidence, and explicitly does not dump the full generated artifact. This adds context beyond the safety hints, though not extensive.
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, front-loads the usage scenario, and efficiently packs the return contents, alternative tool, and parameter constraint without waste.
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?
With an output schema present, the description need not enumerate return fields. It covers when to use, what to expect, and an explicit alternative, making it complete for a decision-brief 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 coverage is 100% with detailed descriptions for repo and package. The description's 'Pass exactly one of repo or package' reinforces the oneOf constraint but adds no new meaning beyond the schema, meriting the baseline score.
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 the action ('CALL when...') and the resource (unfamiliar repository) with specific use cases (depend, fork, learn, deploy). It distinguishes from siblings by naming get_artifact as the alternative for file-level orientation.
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?
Provides clear trigger conditions ('when entering an unfamiliar repository or deciding whether to depend on, fork, learn from, or deploy it') and explicitly recommends get_artifact for file-level needs. Also gives the 'exactly one of repo or package' parameter constraint.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_change_riskPrioritize review for a PR or diffACALL before merging a pull request or after producing a local diff. Returns a deterministic 0-10 change-shape score with receipts for size, spread, missing tests, sensitive paths, hotspots, and blast radius. Pass repo+pr OR diff; repo may accompany diff for cached hotspot context. This prioritizes review and never approves a merge.
| Name | Required | Description | Default |
|---|---|---|---|
| pr | No | Positive pull request number, used with repo. | |
| diff | No | Raw unified git diff to score directly. | |
| repo | No | owner/repo or a github.com URL. |
| Name | Required | Description |
|---|---|---|
| tool | Yes | |
| agent | Yes | |
| status | Yes | |
| schema_version | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive. The description adds valuable behavioral context: deterministic score, receipts for specific risk factors, and that it only prioritizes review without approving. This goes beyond the annotations without contradicting them.
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?
Three sentences, each adding essential information: when to call, what it returns, and parameter relationships. No filler or repetition of schema details.
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?
With an output schema present and strong annotations, the description still covers usage, output composition, and parameter semantics thoroughly. It gives the agent everything needed to select and invoke the tool 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?
Schema coverage is 100%, so the baseline is 3. The description enhances parameter understanding by explaining the valid combinations ('Pass repo+pr OR diff') and the nuance that 'repo may accompany diff for cached hotspot context,' which is not explicitly in the 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?
The description explicitly states it returns a deterministic 0-10 change-shape score for a PR or diff, with specific receipt components (size, spread, missing tests, sensitive paths, hotspots, blast radius). This clearly differentiates it from sibling tools like analyze_repo or compare_repos.
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?
Provides clear timing guidance: call before merging a PR or after producing a local diff. It also states a boundary ('never approves a merge'), but does not explicitly name alternative tools for other use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_dependencyCheck a dependency before adoptionACALL when the user or agent is about to add, upgrade, trust, fork, or deploy an npm package or public GitHub repository. Returns a lean repository-level recommendation, confidence, evidence gaps, CVEs, maintenance, ownership, license, CI/tests, Scorecard, freshness, and next actions. DO NOT use for code navigation. Pass exactly one of repo or package. A favourable result does not validate an exact package version or compatibility.
| Name | Required | Description | Default |
|---|---|---|---|
| repo | No | Public GitHub repository as owner/repo or a github.com URL. | |
| package | No | npm package name, for example lodash or npm:@scope/pkg. |
| Name | Required | Description |
|---|---|---|
| tool | Yes | |
| agent | Yes | |
| status | Yes | |
| schema_version | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is known. The description adds a valuable caveat that a 'favourable result does not validate an exact package version or compatibility,' and clarifies the output is a repository-level recommendation, which goes beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each earning its place: trigger, output contents, exclusion, parameter rule, and caveat. It is front-loaded with the trigger and contains 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?
With a rich output schema and annotations, the description fills the remaining gaps: when to invoke, a clear exclusion, and a critical limitation about version validation. It is complete enough for an agent to decide to use the tool and understand its scope.
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 documents both parameters with descriptions and a oneOf constraint. The description reinforces this with 'Pass exactly one of repo or package,' which adds prose clarity but no new information. Given 100% schema coverage, the baseline of 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 states a specific trigger ('about to add, upgrade, trust, fork, or deploy') and a specific resource ('npm package or public GitHub repository'), followed by a detailed list of returned fields. It also explicitly says 'DO NOT use for code navigation,' which differentiates it from sibling tools like analyze_repo.
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?
It clearly states when to use ('CALL when...') and when not to use ('DO NOT use for code navigation'). It does not name alternative tools, but the explicit trigger and exclusion provide strong guidance for selection among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
compare_reposCompare two repository choicesACALL when the user is choosing between exactly two dependencies or repositories. Returns the preferred candidate for each use case, material trade-offs, confidence, and evidence gaps. Each target is owner/repo, a GitHub URL, an npm package name, or npm:@scope/pkg. Results are cache-only; a missing analysis is reported as not verified rather than guessed.
| Name | Required | Description | Default |
|---|---|---|---|
| a | Yes | First repo or npm package target. | |
| b | Yes | Second repo or npm package target. |
| Name | Required | Description |
|---|---|---|
| tool | Yes | |
| agent | Yes | |
| status | Yes | |
| schema_version | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral context beyond the annotations: 'Results are cache-only; a missing analysis is reported as not verified rather than guessed.' This is a limitation that affects how the agent should interpret results. Annotations already cover read-only, non-destructive, and idempotent traits.
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 a compact paragraph with clear front-loading: the usage condition first, then output, input formats, and behavioral caveat. Every sentence adds value 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?
For a tool taking only two strings, the description covers when to use it, what inputs look like, and a key behavioral limitation. An output schema exists, so return details are not needed. It is sufficiently complete for an agent to select and invoke the tool 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 input schema only says strings, but the description clarifies acceptable formats (owner/repo, GitHub URL, npm package name, or npm:@scope/pkg). This adds meaningful semantics beyond the schema's generic 'First repo or npm package target.'
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 compares exactly two dependencies or repositories, uses the specific verb 'compare', and outlines the output (preferred candidate, trade-offs, confidence, evidence gaps). This distinguishes it from sibling tools like analyze_repo, which likely handles a single repo.
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?
It explicitly says 'CALL when the user is choosing between exactly two dependencies or repositories,' which is a clear trigger condition. It does not explicitly list when-not-to-use or name alternative tools, but the 'exactly two' constraint strongly implies the scope.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_artifactOrient an agent in an unfamiliar repositoryACALL before substantial code work in an unfamiliar repository when the agent needs key files, entry points, architecture hypotheses, a reading order, and verify-before-trusting guidance. Returns the cached CLAUDE.md-style artifact or Cursor rules. Do not call again if the artifact is already in context. Pass exactly one of repo or package.
| Name | Required | Description | Default |
|---|---|---|---|
| repo | No | Public GitHub repository as owner/repo or a github.com URL. | |
| format | No | markdown for CLAUDE.md-style guidance; cursor for .mdc rules. | markdown |
| package | No | npm package name, for example lodash or npm:@scope/pkg. |
| Name | Required | Description |
|---|---|---|
| tool | Yes | |
| agent | Yes | |
| status | Yes | |
| schema_version | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false. The description adds valuable context beyond annotations by noting that the artifact is 'cached' and that the agent should verify-before-trusting, implying potential staleness. It also reinforces idempotency with the explicit 'Do not call again' guidance.
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 three sentences, front-loaded with the most important usage timing ('CALL before substantial code work'), and each sentence adds distinct information: when to use, what it returns, and a critical constraint. No filler or 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 tool is well-specified: it has an output schema for return values, 100% parameter coverage in the schema, and strong annotations. The description covers the situational context, behavior, and constraints. The missing details about return format are handled by the output schema, making the overall definition 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 description coverage is 100% for all three parameters (repo, format, package), so the schema already provides full semantic detail. The description adds only 'Pass exactly one of repo or package,' which is already encoded in the oneOf constraint. No additional parameter insight is provided.
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's purpose: to orient an agent in an unfamiliar repository by returning cached CLAUDE.md-style artifacts or Cursor rules. It uses a specific verb ('CALL') and resource, and scopes the use case to needing key files, entry points, architecture hypotheses, and reading order, which distinguishes it from sibling analysis 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 provides explicit trigger conditions ('before substantial code work in an unfamiliar repository') and a clear when-not-to-call condition ('Do not call again if the artifact is already in context'). However, it does not explicitly name alternative sibling tools or state when to prefer them over this tool.
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.
No comments yet. Be the first to start the discussion!