63-layer continuous-time Symplectic Neural ODE computing topological invariants of real market signals. 256-dim feature space. 27 data products with autonomous Stripe purchase. Property intelligence, DAG manifold computation, federal contracts, distressed real estate. 500K validated embeddings.
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/5.
Most tools are clearly distinct: commerce tools (register_agent, list_products, purchase_data, topup_credits, check_balance) and data tools (list_datasets, fetch_dataset, get_stats) have obvious boundaries. However, get_zk_provenance and verify_footprint both return cryptographic-style proofs and could be misselected despite different purposes (ZK proof for lead ID vs SHA-256 for datasets/records).
All tool names follow a consistent verb_noun snake_case pattern (e.g., check_balance, fetch_dataset, list_products, purchase_data). Even 'topup_credits' and 'get_zk_provenance' fit the pattern, with only minor stylistic variance in verb choice.
10 tools is well-scoped for a credit-based data marketplace. The set covers the full user journey: registration, browsing, purchasing, balance management, data access, and verification. No tool feels redundant or unnecessary.
The tool surface is nearly complete for the marketplace domain: registration, product browsing, purchasing, top-ups, balance checks, dataset listing, record fetching, stats, and two verification methods. A minor gap is the lack of a transaction history or usage log tool, but agents can work around that.
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 only states the action and timing but does not disclose whether the operation is read-only, potential side effects, error handling, or the return format. This is a gap for a tool with no annotation support.
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 primary purpose and a practical usage tip. 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 one-parameter tool with no output schema and no annotations, the description adequately states what it does and when to use it. However, it omits details about the response format or error conditions, which would make it more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single api_key parameter, with a clear description 'Your API key'. The tool description adds no parameter-specific meaning, but the baseline of 3 applies given full schema coverage.
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 resource ('remaining credit balance') and specific verb ('check'). It distinguishes from sibling tools like purchase_data and topup_credits by explicitly focusing on checking the balance after purchases.
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 clear context on when to use: 'Use after purchases to see remaining credits.' It doesn't explicitly state exclusions or alternatives, 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?
No annotations provided, so the description must carry behavioral disclosure. It reveals the free-tier query limit and the need to purchase/top up credits for higher limits, which is important operational context. 'Query' implies a read operation, but it doesn't explicitly state error behavior or whether the tool consumes credits per query.
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, no fluff. The first sentence states what it does; the second adds the crucial limitation and remedy. 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 paginated query tool with 3 simple parameters and no output schema, the description covers core purpose and the key business rule (free tier limit). It doesn't explicitly describe return format or error handling, but 'Query records' implies the result, making it fairly complete for this complexity level.
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%, and the descriptions for limit already include the free-tier constraint. The tool description repeats this but adds no new parameter-level semantics. Baseline of 3 applies because the schema does the heavy lifting.
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?
Clear action verb 'Query', specific resource 'records from a dataset', and explicitly mentions limit/offset. Distinguishes from siblings like list_datasets (which lists available datasets) and get_stats (which returns statistics).
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 by stating the free tier limit of 10 records and advising to purchase products or top up credits for more. This implies when the tool is constrained and what to do next, though it doesn't explicitly name alternative tools like list_datasets or check_balance.
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?
With no annotations, the description carries the full burden of behavioral disclosure. It does not mention whether the operation is read-only, what statistics are computed, or any side effects or limitations, leaving the behavior largely unspecified.
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 focused sentence with no wasted words. However, it is vague enough that a fuller explanation would improve its value while still remaining concise.
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 no parameters, no output schema, and no annotations, so the description must provide sufficient context on its own. It only says 'aggregate statistics from the databases,' leaving unclear what statistics are available, which databases are involved, or how results are returned.
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 the baseline is 4. The description correctly implies no inputs are needed, and there is no additional parameter information required.
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 action ('Get') and resource ('aggregate statistics from the databases'), making the tool's purpose clear. It is distinct from sibling tools like list_datasets or check_balance, though it does not explicitly contrast with them.
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?
There is no guidance on when to use this tool versus alternatives. The description simply states what it does without providing context for appropriate usage or exclusions.
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?
The description discloses that the tool generates a cryptographic proof, implying a read operation, and scopes it to current datasets. However, it does not describe error behavior, whether any authentication is implicitly required, or the format of the returned proof. Since no annotations are present, the description carries the full burden and provides only basic information.
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 concise and front-loaded with the primary action and object. It contains no redundant information, achieving high efficiency.
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 one parameter and no output schema, so the description's one-sentence definition is partially adequate. However, without annotations or output schema, the description does not help the agent understand response structure or failure modes, leaving some gaps for a complete mental model.
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 description for record_id is straightforward and covers 100% of the parameter, so the tool description adds no additional semantic value. The description in the tool text does not elaborate on the record_id format or constraints 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 uses a specific verb 'return' and identifies the resource as 'cryptographic provenance proof for a record ID', clearly distinguishing it from sibling tools like verify_footprint. The scope 'from current datasets' adds useful context. No sibling tool mentions provenance, so this uniquely identifies the tool's purpose.
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?
There is no guidance on when to use this tool versus alternatives such as verify_footprint or fetch_dataset. The description does not mention any prerequisites, exclusions, or typical use cases. This is a significant gap given the related sibling tools.
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?
No annotations are provided, so the description carries the full burden. It discloses that browsing is free and that record counts are included, but doesn't mention output structure, pagination, or any potential side effects. For a zero-parameter list tool, this is adequate but 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?
Two sentences, front-loaded with the core purpose. The second sentence adds relevant examples without redundancy. 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 list tool with no parameters and no output schema, the description is reasonably complete. It includes dataset categories and cost indication. It could mention return format or next steps, but those aren't essential for this straightforward 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?
The input schema is empty, so schema coverage is 100% with zero parameters. The description correctly omits parameter details since none exist. Baseline 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'List all available datasets with record counts' — a specific verb, resource, and output detail. It clearly distinguishes from sibling tools like 'fetch_dataset' (which fetches a specific dataset) and 'list_products' (which lists products, not datasets).
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' gives clear context for when to use the tool (browsing datasets without cost). The listed data categories (market ticks, DePIN stats, etc.) imply exploration use cases. It doesn't explicitly state exclusions or compare to alternatives, but the context is clear enough.
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?
No annotations are provided, so the description carries full burden. It indicates a read-only action via 'Browse' and includes pricing/credit context, but it does not disclose output format, pagination, authorization requirements, or any behavior if called before register_agent. For a tool with no annotations and no output schema, this is insufficient.
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 concise sentences. The first sentence front-loads the purpose, the second gives concrete examples with prices, and the third offers actionable guidance. Every sentence earns its place and there is 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?
The description covers the essential product scope and pricing, and gives usage context. Yet, without an output schema, it does not describe the response structure, field names, or pagination, which would be helpful for a list tool. Still, the provided content is largely sufficient for an agent to understand what to expect.
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, so the baseline according to the rubric is 4. The description adds context about product categories and pricing, but there is no parameter-specific information to clarify. This is appropriate for a 0-parameter tool.
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: 'Browse all purchasable products with prices in credits.' It lists specific product categories and price ranges, and explicitly distinguishes itself from sibling tools like register_agent by saying 'Call after register_agent to see what to buy.' This is a specific verb (browse) + resource (purchasable products) with clear differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: 'Call after register_agent to see what to buy,' which tells the agent when to use this tool. However, it does not mention alternatives or when not to use it, so it stops short of a full 5.
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 convey behavioral traits. It does disclose that the purchase consumes credits and requires an API key, and it enumerates the products available. However, it does not mention outcomes (e.g., what is returned on success/failure), reversibility, or credit insufficiency handling, leaving some 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 two sentences long, highly efficient, and front-loaded with the purpose ('Buy a product with your credits'). The product list is compact and informative, with no redundant phrases.
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 two parameters and no output schema. The description covers the purpose, products, and a prerequisite (api_key). It lacks details about the response format or post-purchase behavior, but given the simplicity and sibling context, it is largely sufficient.
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 both parameters with descriptions, and the tool description adds specificity by naming the API key source (register_agent) and providing product examples (dag_pro, mcp_unlimited). This goes beyond the schema's generic 'Product key to purchase' description, so the added value warrants above baseline.
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 a specific verb ('Buy'), the resource ('product'), and the payment method ('credits'). It also enumerates the specific product catalog, which distinguishes it from sibling tools like topup_credits (adds credits) and register_agent (creates API key).
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 clear context: use this tool to spend credits on listed products, and it references the prerequisite API key from register_agent. It doesn't explicitly contrast with alternatives, but the context and sibling list make the intended usage unambiguous. It could be improved by stating when not to use it (e.g., before topup_credits).
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?
Since there are no annotations, the description carries the full burden. It discloses key behaviors: registration grants immediate credits, requires no credit card/human/Stripe, and provides an API key. It even adds the behavioral nuance 'Credits work immediately.' However, it does not mention edge cases like idempotency (calling twice), what happens if the email is invalid, or whether the API key is returned synchronously, leaving minor 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 concise and front-loaded, starting with the imperative 'START HERE.' Every sentence serves a purpose: purpose, cost removal, immediate utility, and next step. It is neither too terse nor verbose, and it 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 (2 required params, no output schema, no annotations). The description covers the core aspects: purpose, benefits, immediate activation, and post-call action. It doesn't explain the response shape (e.g., where the API key appears) or mention possible errors, but for a registration tool of this simplicity, the description is largely sufficient.
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 both parameters (email and agent_name) with 100% coverage, so the baseline is 3. The description does not add any extra meaning about the parameters themselves; the mention of 'email for delivery and topup notifications' is already in the schema, so no added value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('self-register') and resource ('as an AI agent') with a clear outcome: get $5 free credits and an API key. It also distinguishes itself from all sibling tools by explicitly labeling it as 'START HERE' and the first call, which is unique among the listed 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?
It provides explicit usage guidance: 'Call this first, then call list_products to see what you can buy.' It also lists what the credits can be used for (dataset queries, GPU inference, etc.), giving the agent clear context on when to use this tool and what to do next, with a direct alternative/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 provided, the description works to disclose behavior. It clearly outlines the two payment flows and notes that Stripe requires human involvement. However, it doesn't state what happens after the payment (e.g., immediate credit, confirmation response) or any post-conditions.
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-loaded with the core purpose, and contains no redundant information. Every clause contributes meaningful guidance.
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 handles payments, and the description covers the trigger, the two payment methods, and the human-in-the-loop Stripe step. It lacks details on response behavior (no output schema), but for a payment top-up tool, the operational context is sufficiently clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds value by clarifying the dependency between method and tx_hash: USDC requires tx_hash, while Stripe yields a checkout link. This helps the agent correctly assemble parameters beyond the schema's field-level 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') and the specific trigger ('when your $5 free balance runs out'). It distinguishes itself from siblings like check_balance (which verifies balance) and purchase_data (which buys data) by focusing on the credit top-up action.
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 gives explicit timing ('when your $5 free balance runs out') and details the two payment methods: USDC crypto (with tx_hash) and Stripe (which generates a checkout link for a human). It doesn't explicitly mention alternatives, but the context is sufficient to know when to use this tool.
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 carries the full burden of disclosure. It only says 'Return...' and does not state whether the operation is read-only, requires authentication, or how it handles missing records. This lacks important behavioral context.
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 front-loads the core action. No unnecessary words or repetition.
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 verification tool, the description communicates the main function but leaves gaps: no output schema clarifies the response format, and the ambiguous 'dataset or record' phrasing is unresolved. Without annotations or output schema, more precision is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes both parameters (dataset name and record ID) with 100% coverage. The description adds no extra semantic meaning beyond what the schema provides, so the 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 the tool returns a SHA-256 cryptographic verification, using a specific verb and resource. However, it says 'for a dataset or record' while the schema requires both dataset and record_id, creating ambiguity about the exact scope. This prevents a perfect score.
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 about when to use this tool versus alternatives like get_zk_provenance or fetch_dataset. It does not mention any exclusions, prerequisites, or typical 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!
