Axiom Agentic Tools
Server Details
x402-paid Base agent tools (USDC). 5 deterministic tools. No API keys. No NFT pass.
- 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 targets a distinct domain: revenue auditing, token strategy, grants, gas, security, workflow design, prediction markets, repo health, and wallet balances. No two tools have overlapping purposes, making selection unambiguous for an agent.
All names use lowercase hyphenated format, but prefixes vary (agent-, base-, mcp-, etc.) and some are descriptive while others are domain-based. This is mostly consistent but lacks a uniform pattern like verb-noun.
9 tools is well within the ideal range for a focused server. Each tool addresses a distinct need for autonomous agents on Base, and none feel redundant or unnecessary.
The set covers analysis, planning, and monitoring aspects well (revenue, token, grants, gas, security, workflow, odds, repo, portfolio). Missing execution-oriented tools like token deployment or transaction sending, but for an intelligence-focused suite, this is reasonable.
Available Tools
9 toolsagent-revenue-optimizerAgent Revenue OptimizerARead-onlyInspect
Audit an x402-gated endpoint by probing its 402 envelope, agent-card.json, well-known surfaces, and response headers. Returns a closed-vocabulary verdict plus 3-7 scored recommendations across pricing, bundling, discoverability, envelope correctness, rate limiting, tier expansion, facilitator choice, and schema clarity. Each recommendation cites the observed current-state value as evidence.
| Name | Required | Description | Default |
|---|---|---|---|
| endpoint_url | Yes | Public HTTP(S) URL of the x402-gated endpoint to audit. Must respond with an HTTP 402 envelope on an unauthenticated GET (or POST). Example: https://x402.org or any /api/tools/<slug> on a deployed x402 service. | |
| assumed_monthly_paid_calls | No | Optional estimate of how many paid calls per month the endpoint currently receives. Used to scale recommendation impact_usd_per_month from a per-call delta to a monthly figure. Defaults to 1000 if omitted. |
Output Schema
| Name | Required | Description |
|---|---|---|
| verdict | Yes | |
| evidence | Yes | |
| probed_at | Yes | |
| endpoint_url | Yes | |
| current_state | Yes | |
| next_check_at | No | ISO 8601 timestamp suggesting when the caller should re-invoke this tool. Derived from the tool's recurringHint.intervalSeconds. |
| recommendations | Yes | |
| expected_lift_usd_per_month | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations set readOnlyHint=true and destructiveHint=false, which the description aligns with by describing probing actions without mentioning mutations. The description adds context about probing specific surfaces, enhancing transparency 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?
The description is two sentences, front-loading the action and output structure with no wasted words. Every sentence adds essential 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?
The description outlines the output structure (verdict + recommendations) and categories, complemented by an output schema. It provides sufficient context for understanding the tool's capabilities.
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 thorough parameter descriptions. The description does not add additional meaning beyond what the schema provides, so baseline score 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 uses a specific verb 'Audit' and resource 'x402-gated endpoint', clearly stating the tool's function and distinguishing it from siblings like 'mcp-security-scanner' or 'repo-health-for-agents'.
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 implicitly indicates when to use the tool (for auditing x402 endpoints) but lacks explicit guidance on when not to use it or alternatives. Given the sibling tools are distinct, this is clear but not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
agent-token-strategyAgent Token StrategyARead-onlyIdempotentInspect
Design a non-security token strategy for an autonomous agent. Returns a deployable spec: symbol, supply, distribution allocations summing to 100, OpenZeppelin contract templates (ERC20, ERC4626, ERC721), fair-launch defaults, a six-criterion non-security checklist, an estimated Base deploy cost, and a curated risks list covering Sybil, LP rug, and key-compromise vectors.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Ticker symbol, 2-10 chars, A-Z and digits, leading letter. | |
| pattern | Yes | Which template to base the strategy on. | |
| agent_name | Yes | Display name of the agent the token represents. | |
| include_nft | No | Include an ERC721 access pass alongside the ERC20. | |
| total_supply | No | Optional total supply override. Defaults to template default. |
Output Schema
| Name | Required | Description |
|---|---|---|
| risks | Yes | |
| symbol | Yes | |
| pattern | Yes | |
| decimals | Yes | |
| evidence | Yes | |
| agent_name | Yes | |
| allocations | Yes | |
| generated_at | Yes | |
| total_supply | Yes | |
| next_check_at | No | ISO 8601 timestamp suggesting when the caller should re-invoke this tool. Derived from the tool's recurringHint.intervalSeconds. |
| contracts_to_deploy | Yes | |
| fair_launch_defaults | Yes | |
| non_security_checklist | Yes | |
| deploy_cost_assumptions | Yes | |
| estimated_deploy_cost_usd | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds rich behavioral context: it returns a spec with contracts, checklist, risks, and cost, without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the core action and lists key outputs. It is efficient but slightly long; a minor split could improve 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 the existence of an output schema and annotations, the description covers all essential aspects: the design purpose, detailed output components, and implicit constraints like Base chain. No gaps are evident.
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 baseline is 3. The description does not add meaning beyond the schema's parameter definitions; it focuses on outputs rather than how inputs affect the result.
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: designing a non-security token strategy for an autonomous agent. It lists specific outputs (symbol, supply, contracts, checklist, cost, risks), distinguishing it from siblings like revenue optimizer or grant finder.
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 when to use (for token strategy design) but does not explicitly state exclusions or alternatives. The context from sibling tools provides differentiation, but the description alone lacks 'when-not-to-use' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
base-builder-grant-finderBase Builder Grant FinderARead-onlyIdempotentInspect
Returns a ranked, deadline-aware list of open Base ecosystem funding programs (grants, accelerators, hackathons, retro-funding). Each result cites source_url, deadline, funding_range_usd, and last_verified_at. Stale entries are flagged. Designed for agents and builders shipping on Base who need a single call to surface the next applicable funding deadline.
| Name | Required | Description | Default |
|---|---|---|---|
| stage | No | Current project stage. 'idea' is pre-prototype; 'prototype' has working demo; 'mainnet' has deployed Base contracts; 'scaling' has live users and revenue. Used as an additional eligibility filter against grant stage requirements. Defaults to 'any'. | any |
| category | Yes | Project category. Used to match grant program eligibility and scope. 'ai-agent' covers agent infrastructure, autonomous agents, and agent-economy projects; 'tooling' covers dev tools and SDKs; 'any' returns programs that accept all categories. Required. | |
| max_results | No | Maximum number of ranked program results to return. Programs are scored by match against category, stage, has_live_base_contract, and deadline proximity. Defaults to 10. | |
| has_live_base_contract | No | True if the project already has at least one deployed contract on Base mainnet. Several grants (Base Builder Grants, Coinbase Developer Grants) score higher for live-on-Base projects. Defaults to false. |
Output Schema
| Name | Required | Description |
|---|---|---|
| query | Yes | |
| results | Yes | |
| evidence | Yes | |
| evaluated_at | Yes | |
| next_check_at | No | ISO 8601 timestamp suggesting when the caller should re-invoke this tool. Derived from the tool's recurringHint.intervalSeconds. |
| stale_warnings | Yes | |
| total_open_programs | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and idempotentHint=true. The description adds behavioral context by noting that stale entries are flagged and results are ranked by deadline proximity, providing useful transparency 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, front-loading the main action, then output details, then use case. Every sentence adds value with no 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?
Given the input schema with well-described parameters and the presence of an output schema, the description adequately explains the tool's behavior, output structure, and staleness handling. It is complete for the tool's purpose.
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 has 100% description coverage for all parameters, so the schema already provides detailed meaning. The description does not add parameter-specific information beyond the schema, but it sets overall context. Baseline score 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 clearly states it returns a ranked, deadline-aware list of Base ecosystem funding programs, specifying the output fields and target audience. It distinguishes itself from unrelated sibling 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 states it is 'designed for agents and builders shipping on Base who need a single call to surface the next applicable funding deadline.' This provides clear usage context, though it does not mention when not to use it or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
base-gas-trackerBase Gas TrackerARead-onlyInspect
Live Base network gas tracker. Returns current gas price in gwei, base fee, priority fee (tip), and a block history showing recent gas trends. Useful for timing transactions and estimating costs. $0.01/call.
| Name | Required | Description | Default |
|---|---|---|---|
| blocks | No | Number of recent blocks to include in history (1-20, default 10) |
Output Schema
| Name | Required | Description |
|---|---|---|
| trend | Yes | |
| fetched_at | Yes | |
| base_fee_gwei | Yes | |
| block_history | Yes | |
| gas_price_gwei | Yes | |
| priority_fee_gwei | Yes | |
| max_fee_suggestion_gwei | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark readOnlyHint=true and destructiveHint=false, making safety clear. Description adds that it costs $0.01/call, disclosing a non-obvious behavioral trait (pricing) 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?
Three sentences, front-loaded with core purpose, no redundant information. Every sentence adds value.
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?
Description sufficiently explains what data is returned (gas price, base fee, priority fee, block history). Output schema exists but description complements it well. Simple tool with one parameter, so coverage 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?
Only parameter 'blocks' is fully described in the schema (100% coverage). Description does not add additional semantic meaning 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 it provides live Base network gas tracker returning current gas price, base fee, priority fee, and block history. This distinguishes it from sibling tools which focus on unrelated domains like revenue, security, or workflows.
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 says 'Useful for timing transactions and estimating costs,' implying usage context but lacks explicit when-to-use or alternatives reasoning compared to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
mcp-security-scannerMCP Security ScannerARead-onlyInspect
Scans an MCP server manifest or endpoint for security vulnerabilities — prompt injection in tool descriptions, exfiltration vectors, unbounded resource access, privilege escalation, schema mismatches, transport security issues, and over-permissive scopes. Returns a structured risk report with severity levels and remediation guidance.
| Name | Required | Description | Default |
|---|---|---|---|
| checks | No | Specific check categories to run. Omit to run all checks. | |
| manifestUrl | No | URL of the MCP server manifest (e.g. https://example.com/.well-known/agentic/manifest.json). Mutually exclusive with manifestJson. | |
| manifestJson | No | Raw MCP manifest JSON object to scan. Mutually exclusive with manifestUrl. |
Output Schema
| Name | Required | Description |
|---|---|---|
| summary | Yes | |
| findings | Yes | |
| toolCount | Yes | |
| serverName | Yes | |
| scanTimestamp | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and destructiveHint, so the description's claim of returning a structured risk report aligns with a non-destructive scan. The description adds value by listing specific vulnerability categories and remediation guidance, going beyond the annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no wasted words. The first sentence states the primary function, the second enumerates the scan categories, and the third describes the output. Front-loaded, concise, and efficient.
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 3 parameters (all described) and an existing output schema (implied but not shown), the description covers the tool's scope, inputs, and output type. It does not detail the output structure, but that is left to the output schema. Slightly more context on typical use cases or output format would be beneficial.
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 the description adds limited extra meaning beyond what the schema provides. It does clarify that omitting the 'checks' parameter runs all checks, and re-emphasizes the mutual exclusivity of manifestUrl and manifestJson, but these are already implied by the JSON 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 names the tool's function: scanning MCP server manifests for specific security vulnerabilities, listing seven distinct categories. It clearly distinguishes from sibling tools like agent-revenue-optimizer or repo-health-for-agents, which serve entirely different purposes.
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 indicates when to use the tool (for security scanning) and, by contrast with sibling tools, implies when not. However, it lacks explicit guidance on prerequisites (e.g., needing a manifest URL or JSON) or alternatives. The input schema covers the mutual exclusivity, but the description could be more directive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
multi-agent-workflow-designerMulti-Agent Workflow DesignerARead-onlyIdempotentInspect
Compose a directed acyclic graph of public x402, MCP, and A2A tools that achieves a stated agent goal. Returns step-by-step plan with tool slug, endpoint URL, protocol, inputs, dependencies, per-step cost and latency, total estimated cost, and an executable plan in either a2a-json-rpc or shell-curl form. Useful for autonomous agents that need to pick which paid tools to chain.
| Name | Required | Description | Default |
|---|---|---|---|
| goal | Yes | Plain-English agent goal, e.g. 'sweep top 5 floor NFTs in collection X if contract is safe and gas is low'. | |
| max_steps | No | Cap on number of steps in the returned DAG. | |
| budget_usd | No | Maximum total spend across all chained tool calls. Steps over budget are pruned. | |
| output_format | No | Executable plan format. Defaults to a2a-json-rpc. | |
| preferred_protocols | No | Restrict catalog selection to these protocols. Empty = all. |
Output Schema
| Name | Required | Description |
|---|---|---|
| goal | Yes | |
| steps | Yes | |
| evidence | Yes | |
| fallbacks | Yes | |
| generated_at | Yes | |
| budget_status | Yes | |
| next_check_at | No | ISO 8601 timestamp suggesting when the caller should re-invoke this tool. Derived from the tool's recurringHint.intervalSeconds. |
| output_format | Yes | |
| total_cost_usd | Yes | |
| executable_plan | Yes | |
| total_latency_ms_estimate | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint=true, idempotentHint=true, destructiveHint=false) already indicate safe, read-only behavior. The description adds valuable context about output (plan with cost/latency, executable formats) and the scope (public tools), enhancing transparency 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?
The description is concise at two sentences, front-loaded with the primary action, and contains no unnecessary words or repetition. It efficiently conveys purpose, output, and use case.
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 all parameters documented, the description provides adequate context for a tool of this complexity. It covers the goal, output details, and target users. Minor gap: the description does not explain what specific protocols (x402, MCP, A2A) entail, but this does not hinder fundamental understanding.
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 the schema already documents parameters clearly. The description adds marginal value by framing the tool's context, but does not significantly enhance parameter meaning beyond schema descriptions.
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 compose a directed acyclic graph of specific tool types (x402, MCP, A2A) that achieves an agent goal. It specifies the output (step-by-step plan with details) and distinguishes itself from sibling tools by focusing on paid tool chaining.
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 indicates when the tool is useful: 'for autonomous agents that need to pick which paid tools to chain.' It provides clear context but does not explicitly state when not to use or compare to alternatives, which is acceptable given the tool's specificity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
polymarket-oddsPolymarket OddsARead-onlyInspect
Fetch live prediction market odds from Polymarket. Returns current probabilities, volume, liquidity, and resolution status for any active or resolved market. Accepts a market slug or keyword search term. $0.01/call.
| Name | Required | Description | Default |
|---|---|---|---|
| question | Yes | Polymarket market slug (e.g. 'will-trump-win-2024') or keyword search term |
Output Schema
| Name | Required | Description |
|---|---|---|
| slug | No | |
| end_date | Yes | |
| outcomes | Yes | |
| question | Yes | |
| resolved | Yes | |
| fetched_at | Yes | |
| market_url | No | |
| volume_usd | Yes | |
| liquidity_usd | Yes | |
| resolution_value | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and non-destructive behavior. Description adds value by specifying returned fields (probabilities, volume, liquidity, resolution status) and that it covers both active and resolved markets, exceeding annotation info.
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 concise sentences: purpose, return data, and input format/cost. No wasted 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?
For a simple tool with one parameter, output schema, and annotations, the description is sufficient. It covers input, output highlights, and cost. Lacks error handling or edge cases, but not critical for basic use.
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 parameter description already provided. Tool description repeats 'market slug or keyword search term' but adds no new semantics beyond cost mention, which is not parameter-related.
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?
Clearly states 'Fetch live prediction market odds from Polymarket' with specific verb and resource. No sibling tools overlap in functionality, so it is well-distinguished.
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?
Describes what the tool does and mentions cost, but does not explicitly state when to use or exclude alternatives. Siblings are unrelated, so no direct competition, but guidance is minimal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
repo-health-for-agentsRepo Health AuditorARead-onlyInspect
Comprehensive GitHub repository health audit. Scores repos 0-100 across 8 categories: activity, community, maintenance, contributors, security (via OpenSSF Scorecard), CI/CD, documentation, and popularity. Returns letter grade, per-category scores, 20+ individual checks with evidence, and prioritized recommendations sorted by impact. All checks run via GitHub API — no clone required. Free: 50 calls/IP/day.
| Name | Required | Description | Default |
|---|---|---|---|
| repo | Yes | GitHub owner/name (e.g. vercel/next.js) |
Output Schema
| Name | Required | Description |
|---|---|---|
| repo | Yes | |
| grade | Yes | |
| checks | Yes | |
| metadata | Yes | |
| evaluated_at | Yes | |
| overall_score | Yes | |
| default_branch | Yes | |
| category_scores | Yes | |
| recommendations | Yes | |
| scorecard_detail | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and destructiveHint=false. The description adds operational details: all checks run via GitHub API without cloning, and it specifies output (letter grade, per-category scores, checks, prioritized recommendations). This goes beyond annotations by disclosing API usage and rate limits, enhancing transparency.
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 with no waste. The first sentence captures the core purpose, and the second lists detailed outputs and constraints. Front-loaded and efficient.
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 input (one parameter), annotations, and presence of an output schema, the description fully covers the tool's behavior and output. It explains the scoring system, categories, number of checks, and recommendations, along with operational constraints (no clone, free tier limit). No gaps remain.
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 the single parameter 'repo', which already includes a pattern and example. The description does not add extra semantic meaning beyond what is in the schema. Baseline of 3 is appropriate as no additional value 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 it performs a comprehensive GitHub repository health audit, scoring 0-100 across 8 categories. It uses a specific verb ('audit') and resource ('GitHub repository health'), and the listing of categories and returned items distinguishes it from sibling tools like mcp-security-scanner.
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 context for when to use the tool (for a holistic health audit) and mentions constraints (free 50 calls/IP/day, no clone). It does not explicitly state when not to use it or name alternatives, but the sibling tools are sufficiently different that the intended use is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
wallet-portfolioWallet PortfolioARead-onlyInspect
Fetch token balances for an Ethereum/Base wallet address. Returns ETH, USDC, WETH, AXIOM, and BNKR balances on Base with current USD values from DeFiLlama price data. $0.01/call.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | Ethereum/Base wallet address (0x...) |
Output Schema
| Name | Required | Description |
|---|---|---|
| tokens | Yes | |
| address | Yes | |
| total_usd | Yes | |
| fetched_at | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and destructiveHint; description adds value by specifying returned tokens, USD values from DeFiLlama, and cost ($0.01/call), going 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, front-loaded with purpose, efficient: no wasted words, includes key details (tokens, data source, cost).
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 output schema exists, description covers purpose, specific tokens, data source, and cost adequately for a simple balance 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% and already describes the address parameter with pattern and description; description reinforces wallet address usage but adds little new meaning.
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 fetches token balances for Ethereum/Base wallet addresses, lists specific tokens (ETH, USDC, WETH, AXIOM, BNKR) and mentions Base network, making it distinct from sibling 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?
No explicit guidance on when to use this tool versus alternatives; no when-not-to-use or context provided.
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!