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 3.3/5 across 5 of 5 tools scored.
Each tool targets a distinct area (revenue, token, grants, workflow, repo health) with no functional overlap, making selection unambiguous.
Names use hyphens but prefixes are inconsistent: 'agent-', 'base-builder-', and 'multi-agent-' deviate from a uniform pattern.
5 tools is a compact but reasonable set for a domain-specific server, avoiding bloat while covering key agentic functions.
Covers several agent-related tasks but lacks basic lifecycle tools (e.g., create/deploy agent), leaving notable gaps for an 'agentic tools' server.
Available Tools
5 toolsagent-revenue-optimizerAgent Revenue OptimizerCRead-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?
With no annotations, description must disclose behavior. It states the tool probes an endpoint (network call) and returns verdict and lift, implying read-only. However, it does not mention side effects, authentication needs, rate limits, or whether the probe modifies state. Partially transparent but incomplete.
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, front-loaded with action verb, no wasted words. Very concise but at the cost of omitting important details about parameters and usage. Acceptable trade-off for a simple tool, but could be expanded slightly.
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 and low parameter coverage, the description should provide more context about return values, what a 'verdict' means, how to interpret 'USD lift', and any prerequisites. Currently too sparse for reliable agent decision-making.
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 0% (no parameter descriptions). Description adds minimal meaning: 'endpoint_url' is implied by 'Probe x402 endpoint', but 'assumed_monthly_paid_calls' is unexplained. Agent cannot derive semantics for the optional parameter from the description alone.
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 specifies a verb (Probe), resource (x402 endpoint), and outputs (verdict, expected USD lift). It clearly states the tool's action and return value, though 'lever recommendations' is slightly vague. Distinguishes from sibling tools which are focused on different domains (token strategy, grant finder, workflow, repo health).
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. Lacks context such as prerequisites, when not to use, or comparison to siblings like agent-token-strategy. The description implies usage for revenue optimization but provides no situational cues.
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 StrategyBRead-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?
No annotations are provided, so the description must bear full responsibility. It implies a read-only design output but does not explicitly state behavioral traits like destructive actions, authorization needs, 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 a single sentence that is efficient and front-loaded with the primary action. However, it is somewhat verbose and could be more concise without losing meaning.
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 no output schema and no annotations, the description should provide more context about return values, error conditions, or parameter interactions. It falls short in covering these aspects.
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 all parameters. The description does not add further meaning beyond listing deliverables, earning 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 designs a non-security token strategy for an autonomous agent, listing deliverables (supply, allocations, contracts, checklist, risks). This distinct purpose sets it apart from siblings like agent-revenue-optimizer.
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 guidance on when to use this tool versus siblings; no prerequisites or exclusions mentioned. The description lacks context for appropriate usage.
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 FinderBRead-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?
No annotations provided, so description carries full burden. It discloses ranking by deadline and category fit with citations, implying a read-only operation, but does not explicitly state side effects (none expected) or behavioral traits like rate limits or data freshness.
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 with no redundancy. Front-loaded with key information (ranking, types, criteria, citations). Every word is purposeful.
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 and 4 parameters, the description provides the core purpose but lacks details on return format, sorting behavior, or how citations are presented. It is adequate for simple use but incomplete for nuanced invocation.
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 0%. The description only mentions 'category fit' and 'deadline', but does not explain parameters like stage, max_results, has_live_base_contract, or how they affect results. It adds little meaning beyond 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 clearly states the tool ranks grants, accelerators, hackathons, and retro funding with specific criteria (deadline and category fit) and cites sources. It uses a specific verb 'Rank' and resource 'open Base builder grants...', distinguishing it from sibling tools like 'agent-revenue-optimizer'.
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 guidance on when to use this tool vs siblings or alternatives. It does not mention exclusions, prerequisites, or context for selection. The description lacks explicit usage direction.
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?
No annotations exist, so the description must fully disclose behavior. It only says 'Plan a DAG' but does not clarify whether the tool executes the plan or simply returns it. Additionally, it omits authentication, rate limits, or side effects, leaving significant gaps.
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 of 16 words with no redundancy. Every word is necessary, and it avoids fluff while communicating the core purpose.
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 no output schema, the description should hint at the return value. It says 'Plan a DAG' but does not mention that the tool likely returns a plan structure or executable format. For a tool with 5 parameters, the description is adequate but lacks return details.
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 baseline is 3. The description adds no extra meaning beyond the schema; it does not explain how parameters interact (e.g., budget pruning steps). Thus, no value added.
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 plans a DAG of x402, MCP, and A2A tool calls to hit a goal under budget. It specifies the verb 'plan' and the resource 'DAG', and implicitly distinguishes from unrelated siblings. However, it uses vague phrasing like 'hits the goal' without elaborating on success conditions.
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 a multi-step workflow with budget constraints is needed. It does not provide explicit when-not or alternatives, but siblings are clearly different domains, so no confusion arises.
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 for AgentsARead-onlyInspect
Free agent-marketplace-readiness audit. Runs a 15-check scorecard (agent-card, MCP descriptor, OpenAPI, llms.txt, x402 envelope, CDP facilitator, Bazaar discoverability, ERC-8257 registration, ERC-8004 identity, CI demo, schema drift, README marketplace mentions, license) on any public GitHub repo plus an optional deployed URL. Returns overall_score (0-100), four 25-point category scores, and prioritized fixes ranked by score lift. Rate-limited 50 calls per IP per day; for higher volume call the paid tools the fix list points at (agent-revenue-optimizer, agent-token-strategy, multi-agent-workflow-designer, base-builder-grant-finder).
| Name | Required | Description | Default |
|---|---|---|---|
| repo | Yes | GitHub owner/name (e.g. 0xAxiom/axiom-agentic-tools) | |
| branch | No | Optional branch (defaults to default branch on GitHub) | |
| deployed_url | No | Optional deployed base URL to probe (e.g. https://axiom-agentic-tools.vercel.app) |
Output Schema
| Name | Required | Description |
|---|---|---|
| repo | Yes | |
| checks | Yes | |
| evidence | Yes | |
| deployed_url | 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. |
| overall_score | Yes | |
| default_branch | Yes | |
| category_scores | Yes | |
| prioritized_fixes | Yes | |
| marketplace_listing_eligibility | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description alone must disclose behavioral traits. It mentions a '15-check scorecard and prioritized fixes' but does not clarify if the audit is read-only, requires permissions, or has any side effects. The lack of detail on safety or side effects leaves ambiguity.
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 efficient sentence that front-loads the action. It could be slightly more structured to separate the audit actions and output but is concise without being too terse.
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 3 parameters, no output schema, and no annotations, the description covers the input and general output (scorecard and fixes) but lacks details on return format or pagination. It is adequate for understanding the tool's purpose but leaves agents needing to infer the output structure.
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 the description adds context by tying the 'deployed_url' parameter to the audit target. It reinforces the purpose of each parameter (repo, optional branch, optional deployed URL) beyond the 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 audits a GitHub repo and deployed URL for readiness in agent marketplace, MCP, and x402, producing a scorecard with fixes. The verb 'Audit' and specific targets distinguish it from sibling tools like agent-revenue-optimizer or agent-token-strategy.
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 for auditing repo health for specific standards, but it does not explicitly state when to use or avoid this tool compared to alternatives. No exclusion criteria or alternative tools are mentioned, leaving the agent to infer context from sibling names.
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!