256-dim DAG Manifold engine. 10 MCP tools. 27 Stripe products. Free tier: 50 queries/day.
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., master_leads) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the free-tier quota and that purchases/top-ups extend it, but does not mention return format, error behavior, or whether authentication is required. The quota is useful, but more behavioral detail (e.g., what happens if limit exceeded) would improve transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with purpose and followed by a critical constraint. Every word earns its place, and it's immediately scannable for an agent.
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, the description is mostly complete: it tells the agent how to paginate and about the free-tier limit, which connects to sibling tools. However, the absence of an output schema means the description could have hinted at return structure, but this is a minor gap given the tool's simplicity.
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 no parameter meaning beyond the schema; the limit constraint already appears in the schema description. Offset remains simply 'Record offset' with no additional context.
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.' This specifies the verb (query), resource (dataset), and key behaviors (pagination), distinguishing it from siblings like list_datasets or get_stats.
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 clear context on how to use the tool (query with limit/offset) and mentions a key constraint (free tier: 10 records per query). It implies that to exceed this, one must use purchase_data or topup_credits, but it doesn't explicitly exclude or compare alternatives.
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 zero-knowledge provenance proof for a lead ID
| Name | Required | Description | Default |
|---|---|---|---|
| lead_id | Yes | Lead 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 must convey behavioral traits. It only says 'Return', implying a read operation, but does not explicitly state if it is read-only, what permissions are needed, or whether any side effects occur.
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 extraneous words. It is front-loaded with the action and key object, making it 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 output schema or annotations, the description fails to explain what the provenance proof looks like or how it is structured. For a specialized tool, this leaves gaps in understanding for the agent.
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 the lead_id parameter with 100% coverage, so the description adds no new semantic information beyond what the schema provides, 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 action (Return) and the resource (zero-knowledge provenance proof) along with the required input (lead ID). It distinguishes itself from siblings like verify_footprint by specifically focusing on provenance proofs.
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 the tool is used when a provenance proof is needed for a lead, but it does not provide explicit guidance on when to use this tool versus alternatives like verify_footprint, nor does it mention any prerequisites or exclusions.
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 — 23K+ property leads, 168K weather alerts, 122K earthquakes, 14.6K federal register entries.
| 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 must carry the behavioral disclosure burden. It adds value by stating 'Free to browse' (cost behavior) and providing record counts, but it does not explicitly confirm read-only safety, pagination behavior, or return format. This is adequate for a simple list tool, but not rich.
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, front-loaded sentence that wastes no words. It immediately states the action and resource, then adds concrete examples of dataset contents, making it highly efficient and scannable.
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 low complexity (no parameters, no output schema), the description fully covers what the tool does, what it returns (dataset list with record counts), and the cost context. It is sufficiently complete for an agent to select and invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there are no parameter semantics to explain. Per the rubric, a 0-parameter tool gets a baseline of 4, and the description appropriately needs no parameter details.
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 verb 'List' and the resource 'all available datasets', with specific record counts and examples. This distinguishes it from siblings like fetch_dataset, get_stats, and list_products, which target different operations.
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 that this is a no-cost discovery operation, appropriate for exploring available datasets. It does not explicitly name alternatives or exclusions, but the purpose is evident from the name and description, so it earns a 4 rather than a 5.
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 distressed property lead packs ($0.49-$24.99), 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 provided, the description carries the full burden. It conveys a read-only browsing action ('Browse all purchasable products') and adds pricing details, including the credit conversion. It doesn't explicitly state there are no side effects, but the verb 'browse' strongly implies non-destructive behavior, and the absence of destructive language mitigates the risk.
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 long and front-loaded with the primary purpose. The included price ranges and product types are relevant and help an agent understand the catalog, but some of this detail could be trimmed without losing essential meaning. It remains compact and readable.
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 covers the necessary contextual information: what products are listed, indicative price ranges, and when to call it. A minor gap is the lack of mention of return format or pagination, but for a simple list tool this is not critical.
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 input schema is vacuously fully covered. Per the rubric, a zero-parameter tool gets a baseline of 4. The description does not need to add parameter-level detail since there are none.
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 with a specific verb ('browse') and resource ('all purchasable products'), and provides concrete examples (distressed property lead packs, signal feed tiers, API access, GPU compute, MCP). This clearly distinguishes it from sibling tools like list_datasets and purchase_data.
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 offers explicit contextual guidance: 'Call after register_agent to see what to buy.' This tells the agent when in the workflow to use it. It does not name alternatives or exclusions, but the usage context is clear enough to infer it is for browsing before purchase.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
purchase_dataAInspectBuy any product with your credits. Returns instant CSV download URL for lead packs. Products: houston_metro_leads ($2.99, 1300 leads), all_tx_enriched ($4.99, 1354 TX leads), dfw_multifamily ($4.95, 290 leads), platinum_dossiers ($24.99, federal contracts), foreclosure_leads ($0.49, 50 leads), anna_tx_leads ($1.49), pasadena_tx_leads ($0.99). 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. houston_metro_leads, foreclosure_leads) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses the action (buying with credits, implying deduction), the return value (instant CSV download URL), and product specifics (names, prices, lead counts). It does not mention failure conditions like insufficient credits or invalid product keys, but the core behavior is adequately conveyed.
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 paragraph, but every sentence provides essential information: the action, the return format, the product catalog, and the api_key dependency. While the product list is lengthy, it directly maps to the product_key parameter, making it valuable. However, the structure could be improved with bullet points for readability, and there is some redundancy with the schema's api_key description.
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 annotations and no output schema, the description explains the return value (CSV URL), lists all products, and specifies the required api_key. It does not cover edge cases like insufficient credits or duplicate purchases, but for a straightforward purchase tool with two parameters, this is reasonably complete. It also implicitly differentiates from siblings like fetch_dataset and list_products.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with basic descriptions, but the description adds significant value by enumerating all valid product_key values with prices and lead counts (e.g., 'houston_metro_leads ($2.99, 1300 leads)'). It also reinforces the api_key parameter by referencing its source (register_agent). This far surpasses the schema's minimal parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Buy any product with your credits.' It uses a specific verb ('buy') and resource ('product'), and further differentiates from siblings like list_products and topup_credits by naming specific purchasable products and their prices.
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 sets clear context for use: it is for purchasing products with credits, returning a CSV download URL. It also instructs to 'Use api_key from register_agent,' but does not explicitly mention when to avoid this tool (e.g., when just viewing products or adding credits). The presence of sibling tools like list_products and topup_credits implies boundaries, but the description itself lacks explicit exclusionary guidance.
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 purchasing lead packs. 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 burden of behavioral disclosure. It discloses key behaviors: no credit card/human/Stripe required, credits work immediately, and it produces an API key. However, it does not mention idempotency or what happens on duplicate registration, though this is minor 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 concise and front-loaded: it starts with an attention-grabbing 'START HERE', followed by a clear statement of purpose and benefits, then a direct next step. Every sentence adds value, and the overall length is appropriate for the tool's simplicity.
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 required parameters and no output schema, the description is remarkably complete. It covers the purpose, the immediate benefit ($5 credits, API key), the operational details (no credit card), and the recommended next action (call list_products). This is sufficient for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides full coverage (100%) with descriptions for both 'email' and 'agent_name'. The description adds context by framing them as part of self-registration ('your agent name'), but it does not significantly enhance beyond the schema's own parameter descriptions. 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 the tool's purpose: 'Self-register as an AI agent to get $5 free credits and an API key.' It uses a specific verb ('register') and resource ('AI agent'), and distinguishes itself from sibling tools by being the entry point. The 'START HERE' tag further emphasizes its unique role.
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?
Explicit usage guidance is provided: 'Call this first, then call list_products to see what you can buy.' It also clarifies when to use this tool relative to others and what the credits can be used for (dataset queries, GPU inference, etc.), making the usage context unmistakable.
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!