DePIN telemetry, DAG manifold correlation, and verifiable data products for AI agents.
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 3.9/5 across 10 of 10 tools scored. Lowest: 3.1/5.
Most tools have clearly distinct purposes: account management, browsing, purchasing, querying, and verification. However, get_zk_provenance and verify_footprint both deal with data verification, and the distinction between list_datasets and list_products could be slightly ambiguous without reading descriptions carefully.
All tool names follow a strict snake_case verb_noun pattern (e.g., register_agent, list_products, topup_credits). The verbs are descriptive and consistent, making the tool set predictable and easy to navigate.
The 10 tools cover a complete marketplace workflow without excess. Each tool serves a clear function, from registration and billing to data access and verification, and the count is within the ideal 3-15 range.
Core lifecycle is well-covered: register, browse, purchase, query, and verify data. However, subscription management (e.g., canceling or changing tiers) is not explicitly supported, and there is no purchase history tool, leaving minor gaps for account administration.
check_balanceAInspectCheck your remaining credit balance. Use after purchases to see remaining credits.
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | Yes | Your API key |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the action and timing but does not explicitly mention that it is a read-only operation or any other behavioral traits. The name and description imply safety, but this is not formally disclosed.
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, concise sentence with no wasted words. It conveys purpose and usage context efficiently.
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 one-parameter tool with no output schema, the description is adequate. It tells what the tool does and when to use it. Slightly more could be added about response format or authentication, but these are not essential for this straightforward action.
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 schema covers the single parameter 'api_key' with description 'Your API key' (100% coverage). The description adds no additional parameter information, so the baseline of 3 applies.
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 verb and resource: 'Check your remaining credit balance.' It clearly distinguishes from sibling tools like purchase_data and topup_credits by focusing on the query action for balance.
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 context with 'Use after purchases to see remaining credits,' indicating when it is appropriate to invoke. No explicit alternatives or when-not-to-use guidance, but the context is sufficient for this simple tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
fetch_datasetAInspectQuery records from a dataset with limit/offset. Free tier: 10 records per query. Purchase products or top up credits for more.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max records (max 10 for free tier) | |
| offset | No | Record offset | |
| dataset | Yes | Dataset name (e.g., depin_stats) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses a key behavioral constraint: 'Free tier: 10 records per query. Purchase products or top up credits for more.' This is valuable since no annotations are provided. However, the free tier limit is already present in the schema's limit parameter description ('max 10 for free tier'), so the description adds only the purchasing context, not substantial new behavioral detail. It does not mention error handling or return structure, but the core limitation is covered.
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 short sentences, front-loaded with the core purpose and immediately followed by a key limitation. There is no redundant or filler content; every word 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?
For a simple query tool with three straightforward parameters and no output schema, the description covers the essential purpose and a notable limitation. It could be slightly improved by mentioning that records are returned or noting the dataset must exist, but given the tool's simplicity, it is adequately 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?
The input schema describes all three parameters (limit, offset, dataset) with sufficient detail, achieving 100% schema description coverage. The tool description does not add any extra semantic meaning beyond what the schema already provides; it only mentions limit/offset by name. With high schema coverage, a 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 clearly states the tool's function: 'Query records from a dataset with limit/offset.' It specifies the resource (dataset) and the action (query), with pagination details. This distinguishes it from siblings like list_datasets, which lists datasets rather than records from a specific dataset.
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: you use this tool to fetch records from a dataset. It also mentions the free tier limit and the need to purchase products or top up credits for more, which gives some context on when to expect limitations. However, it does not explicitly state when to use this tool over alternatives (e.g., list_datasets for exploring available datasets) or provide exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_statsBInspectGet aggregate statistics from the databases
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must convey behavioral traits. It implies a read-only operation but does not explicitly state safety, performance implications, or any non-obvious behaviors. The minimal description 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 sentence with no unnecessary words. It is concise and front-loaded. However, it could be slightly expanded to add value without losing brevity.
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 has no parameters and no output schema, the description is the sole source of context. It states the general purpose but lacks details on the type of statistics, return format, or any usage constraints. It is minimally 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?
There are no parameters, and schema description coverage is 100% by default. The description does not need to add parameter info beyond what the schema provides, as per the baseline of 4 for zero-parameter tools.
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 'Get aggregate statistics from the databases' clearly states a verb and resource, distinguishing it from siblings like fetch_dataset or list_datasets. However, it is somewhat generic.
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 is provided on when to use this tool versus alternatives like list_datasets or verify_footprint. The description lacks any 'when-to-use' or 'when-not-to-use' information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_zk_provenanceAInspectReturn cryptographic provenance proof for a record ID from current datasets.
| Name | Required | Description | Default |
|---|---|---|---|
| record_id | Yes | Record ID to get provenance for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It implies a read-only operation by saying 'return', but it does not disclose the format of the proof, any prerequisites, or potential side effects. Some transparency exists but it is minimal.
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, concise sentence that fronts the key action (return) and object (provenance proof). It contains no extraneous information and is easy to parse.
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 annotations and no output schema, the description should explain what a 'cryptographic provenance proof' looks like or how it will be returned. It also doesn't mention any error conditions or dataset context beyond 'current datasets', leaving significant gaps for an agent that needs to interpret results.
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% coverage for record_id, describing it as 'Record ID to get provenance for.' The description does not add significant meaning beyond the schema; the 'from current datasets' qualifier refers to the tool's scope rather than the parameter itself. Baseline 3 applies.
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: 'Return cryptographic provenance proof for a record ID from current datasets.' It uses a specific verb ('return') and a specific resource ('cryptographic provenance proof'), which distinguishes it from sibling tools like check_balance, fetch_dataset, or verify_footprint.
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 phrase 'from current datasets' implies a constraint, but there is no explicit guidance on when to use this tool versus alternatives, nor any stated exclusions. The purpose is distinct enough that an agent can infer basic usage, but it lacks explicit alternatives or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_datasetsAInspectList all available datasets with record counts. Free to browse — market ticks, DePIN network stats, technical indicators, US county atlas, ZK footprints.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the key trait 'Free to browse' (no cost) and states the primary behavior of listing datasets with record counts. It does not mention return format details or pagination, but for a simple listing tool, the core behavioral aspects are covered.
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 wasted words. The primary action is front-loaded ('List all available datasets'), and the second sentence adds useful examples without redundancy. Every element 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?
The tool is simple with no parameters, output schema, or annotations, so the description must carry everything. It explains the purpose, the included record counts, and the free browsing aspect, and gives concrete dataset examples. It does not specify output format beyond counts, but this is adequate for a listing tool given sibling tools handle detailed fetching.
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 tool has zero parameters, so per the rubric a baseline of 4 applies. The description adds value by explaining what the output includes (record counts) and what kinds of datasets are covered, which fulfills the semantic burden despite no parameters.
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 'List' with a clear resource 'all available datasets' and specifies that it includes 'record counts'. This distinguishes it from siblings like fetch_dataset (which retrieves a specific dataset) and list_products (which lists products). The additional examples of dataset types further clarify scope.
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 phrase 'Free to browse' implies it's a safe, exploratory operation, but it does not explicitly state when to use this tool versus alternatives like fetch_dataset for detailed data or list_products for products. The guidance is implied rather than explicit, with no exclusions or alternative tool mentions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_productsAInspectBrowse all purchasable products with prices in credits ($1 = 1 credit). Includes DePIN supply-telemetry data, signal feed tiers ($9.99-$399.90/mo), DAG manifold API ($2.99-$9.99/mo), GPU compute, and MCP unlimited access. Call after register_agent to see what to buy.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It uses 'Browse' to imply a read-only operation and details the content (products, pricing, categories). It does not explicitly state side effects or pagination, but for a simple list tool, this is 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 only. The first states the core function, the second adds examples and a usage hint. Every word earns its place, with great front-loading of the main 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?
For a tool with no parameters and no output schema, the description is remarkably complete. It tells what the tool returns, gives pricing details, lists examples, and provides a prerequisite. Nothing critical is missing.
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 tool has zero parameters and the schema is empty, with 100% coverage. The description adds meaningful context about what the returned list contains (prices, categories, examples), which goes beyond the empty schema. Baseline for zero params is 4.
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 'Browse all purchasable products with prices in credits', which is a specific verb+resource+scope. It also distinguishes itself from sibling tools like list_datasets by focusing on purchasable products rather than datasets, and provides concrete examples of product categories.
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 a clear usage context: 'Call after register_agent to see what to buy.' This tells the agent when to use the tool in a sequence, but does not explicitly mention alternatives or when not to use it, so it stops short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
purchase_dataAInspectBuy a product with your credits. Products: DePIN supply-telemetry snapshots, DAG manifold API (dag_pro/dag_quant/dag_enterprise), signal feed tiers, GPU compute, MCP unlimited. Use api_key from register_agent.
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | Yes | Your API key from register_agent | |
| product_key | Yes | Product key to purchase (e.g. dag_pro, mcp_unlimited) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral side effects. It mentions 'with your credits' implying a deduction, but does not mention whether the purchase is reversible, what happens on insufficient balance, or what the response contains. For a financial mutation tool, this is a significant transparency gap.
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 states the core action, the second provides necessary product context and API key source. No redundant wording; every element 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?
This is a purchase tool with financial implications, no output schema, and no annotations. The description does not explain success/failure behavior, error conditions (e.g., insufficient credits), or post-purchase expectations. It is minimally viable but leaves significant gaps for an agent to invoke correctly in edge cases.
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 schema already covers both parameters with examples, but the description adds a comprehensive product catalog (DePIN snapshots, DAG manifold API, signal feed tiers, GPU compute, MCP unlimited) that goes beyond the schema's two example keys, helping the agent select a valid product_key.
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 'Buy a product with your credits' and enumerates specific product categories and keys, distinguishing it from sibling tools like register_agent and topup_credits which handle credential registration and balance top-up respectively.
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 the prerequisite of using the api_key from register_agent and lists purchasable products, but it does not explicitly state when to use this tool versus alternatives (e.g., topup_credits for recharging credits, or check_balance for viewing funds). The usage context is implied rather than explicitly contrasted with siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
register_agentAInspectSTART HERE. Self-register as an AI agent to get $5 free credits and an API key. No credit card, no human, no Stripe required. Credits work immediately for dataset queries, GPU inference, DAG manifold computation, and DePIN/API access. Call this first, then call list_products to see what you can buy.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | Contact email (for delivery and topup notifications) | ||
| agent_name | Yes | Your agent name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It reveals that the tool grants free credits that work immediately, gives an API key, and requires no human interaction. It adds meaningful behavioral context but does not discuss idempotency or error scenarios. Despite this, the description is quite transparent for a registration 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?
The description is three sentences, front-loaded with 'START HERE,' and every sentence delivers distinct value: purpose, constraints, and next-step guidance. 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?
For a simple registration tool with two parameters and no output schema, the description covers the essential aspects: what it does, prerequisites (none), immediate effect, and the recommended next action. It could mention response details, but the 'API key' implies the outcome, making it mostly 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%, so the parameters (email, agent_name) are fully described in the input schema. The description adds no additional parameter-specific semantics beyond the schema, so the baseline 3 applies.
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 'START HERE' and 'Self-register as an AI agent to get $5 free credits and an API key.' It specifies the verb (register), resource (agent), and expected outcome, while distinguishing itself from sibling tools as the initial onboarding step.
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?
Explicitly instructs 'Call this first' and 'then call list_products to see what you can buy,' providing a clear when-to-use directive. Also notes no credit card, no human, or Stripe is required, setting expectations for prerequisites. This is strong usage guidance with a named alternative for the next step.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
topup_creditsAInspectAdd credits when your $5 free balance runs out. Pay via USDC crypto (provide tx_hash) or get a Stripe checkout link for your human operator to complete.
| Name | Required | Description | Default |
|---|---|---|---|
| amount | Yes | Amount in USD to add | |
| method | Yes | Payment method | |
| api_key | Yes | Your API key | |
| tx_hash | No | USDC transaction hash (for crypto payments) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the transparency burden. It does disclose that Stripe returns a checkout link for human completion and that USDC requires a tx_hash. However, it doesn't explain what happens after payment (immediate credit vs. async), whether there are any approval steps, or what response to expect (e.g., confirmation, receipt). These are notable gaps for a financial transaction 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?
The description is two sentences with no filler. It front-loads the purpose and then provides method details. Every word contributes to understanding the tool's purpose and usage.
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?
While the description explains the two payment modes, it omits what the tool returns for USDC payments (does it just acknowledge?), any time delays, and whether the Stripe link is generated synchronously. Since there is no output schema, the description should clarify expected outcomes. The tool is moderately complex due to the two methods, so the missing return/behavioral details leave a gap.
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 schema already describes all 4 parameters, so the baseline is 3. The description adds meaningful context by clarifying that tx_hash is for USDC payments and that the Stripe flow produces a checkout link for a human to complete. This links the parameters to the real-world flow, going beyond the schema's simple field 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 action ('Add credits'), the context ('when your $5 free balance runs out'), and the two payment methods (USDC or Stripe). This distinguishes it from siblings like check_balance (read-only) and purchase_data (buying data, not adding account credit).
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 when to use the tool ('when your $5 free balance runs out') and describes the two payment paths, including that Stripe requires a human operator. It doesn't explicitly mention alternatives, but the context is clear enough because no sibling tool provides this top-up function.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
verify_footprintBInspectReturn SHA-256 cryptographic verification for a dataset or record
| Name | Required | Description | Default |
|---|---|---|---|
| dataset | Yes | Dataset name | |
| record_id | Yes | Record ID to verify |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states the tool returns a SHA-256 verification but does not clarify if it is read-only, whether any side effects occur, or what the output format is.
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, clear sentence with no superfluous words. It is 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?
The tool has two required parameters, no output schema, and a brief description. It does not explain the return format (e.g., is it a hex string?), error scenarios, or authentication requirements. For a cryptographic verification tool, this is insufficient.
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 descriptions in the schema already explain the parameters ('Dataset name', 'Record ID to verify'). The tool description adds no extra meaning beyond the schema, 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 'Return SHA-256 cryptographic verification for a dataset or record', using a specific verb and resource. It distinguishes from sibling tools like fetch_dataset or get_zk_provenance by specifying the cryptographic nature.
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 alternatives such as get_zk_provenance or fetch_dataset. The description does not mention any prerequisites, constraints, or use cases.
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!