PressureDesk
Server Details
Read-only BUY / WAIT / AVOID spend gate for paid APIs, MCP endpoints, and x402 routes.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 3.2/5 across 9 of 9 tools scored. Lowest: 2.6/5.
Each tool targets a specific aspect of PressureDesk (home, evaluation, access, freshness, dossier, payment, metadata, preview, source health), with only minor overlap between 'freshness' and 'source_health' both mentioning freshness, but descriptions differentiate them clearly.
All tools share the 'pressuredesk_' prefix, but the suffixes vary in form (e.g., noun 'freshness', verb phrase 'evaluate_tool', imperative 'get_dossier'). The pattern is mostly consistent with minor grammatical inconsistency.
With 9 tools, the server covers its apparent domain comprehensively without being overwhelming. The count is well within the ideal 3-15 range for focused servers.
The tools cover information retrieval and status checking well, but lack actions like listing entities or creating snapshots. Given the read-only emphasis, minor gaps exist but do not severely hinder the core purpose.
Available Tools
9 toolspressuredesk_agent_homeAutonomyForge Agent HomeBRead-onlyIdempotentInspect
Return the public-safe one-call AutonomyForge product storefront and next action.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| kind | No | Machine-readable response kind, for example source-health, agent-home, or tool-buyer-dossier. |
| status | No | Readiness, payment, or request status when present. |
| product | No | Product name when the response is a public product or route packet. |
| decision | No | BUY / WAIT / AVOID decision packet when the tool evaluates a paid target. |
| trustPacket | No | Receipt, freshness, source, and safety-boundary information for agent spend decisions. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits such as side effects, authentication needs, rate limits, or what happens if the tool fails. The statement is minimal and lacks 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 a single, concise sentence that communicates the core functionality without unnecessary words. It is front-loaded with the action and resource.
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 minimally adequate. However, it could be improved by briefly describing the nature of the returned storefront or next action to provide a clearer picture of the output.
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 no parameters, so the input schema is fully covered. The description does not need to add parameter meaning, but it also does not provide any additional context about expected inputs, which is acceptable given the straightforward nature.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns the 'public-safe one-call AutonomyForge product storefront and next action', indicating a specific verb and resource. It effectively distinguishes from sibling tools which focus on evaluation, access, or health.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor any prerequisites or exclusions. The description only states what the tool does without contextual usage advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pressuredesk_evaluate_toolEvaluate Paid Tool SpendBRead-onlyIdempotentInspect
Return a read-only BUY / WAIT / AVOID spend-gate packet before an agent pays for a target API, MCP endpoint, or tool.
| Name | Required | Description | Default |
|---|---|---|---|
| task | No | Buyer task or agent intent that explains why the target might be worth paying for. | |
| target | Yes | Paid API, x402 endpoint, MCP server, or tool URL to evaluate before spend. | |
| priceUsd | No | Quoted target price in USD for this one prospective call. |
Output Schema
| Name | Required | Description |
|---|---|---|
| kind | No | Machine-readable response kind, for example source-health, agent-home, or tool-buyer-dossier. |
| status | No | Readiness, payment, or request status when present. |
| product | No | Product name when the response is a public product or route packet. |
| decision | No | BUY / WAIT / AVOID decision packet when the tool evaluates a paid target. |
| trustPacket | No | Receipt, freshness, source, and safety-boundary information for agent spend decisions. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description uses 'read-only' but no annotations exist to reinforce this. It fails to disclose other behavioral aspects such as idempotency, side effects, or authorization requirements. The description carries the full burden but provides minimal 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 sentence that efficiently conveys the tool's purpose and output. It is well-structured and front-loaded, but the extreme brevity leaves out potentially important details without being redundant.
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 three parameters and lack of output schema, the description should explain parameter roles and return format. It does not, leaving the agent underinformed about how to invoke the tool or 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?
Schema description coverage is 0%, yet the description adds no meaning to any of the three parameters (task, target, priceUsd). The parameter names offer limited clues, but without further explanation, the agent cannot understand how to set or interpret them correctly.
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 'BUY / WAIT / AVOID' packet and specifies the use case: evaluating spending before paying for an API, MCP endpoint, or tool. It uses specific verbs and resource types, distinguishing it from sibling tools like 'live_payment_status' or 'source_health'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear context ('before an agent pays') but does not explicitly state when not to use this tool or suggest alternatives. While the sibling tools differ in purpose, no direct exclusion or guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pressuredesk_founding_accessPressureDesk Founding AccessBRead-onlyIdempotentInspect
Return the read-only manual founding-access request packet, required fields, disallowed secrets, and buyer proof links.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| kind | No | Machine-readable response kind, for example source-health, agent-home, or tool-buyer-dossier. |
| status | No | Readiness, payment, or request status when present. |
| product | No | Product name when the response is a public product or route packet. |
| decision | No | BUY / WAIT / AVOID decision packet when the tool evaluates a paid target. |
| trustPacket | No | Receipt, freshness, source, and safety-boundary information for agent spend decisions. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should fully disclose behavioral traits. It mentions 'read-only' which is positive but omits auth requirements, rate limits, or any side effects. Insufficient for a zero-annotation 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?
A single sentence that is concise but slightly overloaded with comma-separated items. It front-loads the purpose well, but the structure could be clearer. 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?
Given zero parameters and no output schema, the description tells what the tool returns but lacks context on how it fits into the workflow with sibling tools. The mention of 'manual founding-access request packet' is specific but may not be fully understood without broader context.
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, so baseline is 4. The description adds high value by specifying the contents of the returned packet (manual founding-access request packet, required fields, disallowed secrets, buyer proof links), which goes beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that it returns a read-only manual founding-access request packet with specific components, using a specific verb ('Return') and resource. However, it does not differentiate this tool from siblings like 'pressuredesk_get_dossier' or 'pressuredesk_meta'.
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; no context on prerequisites or exclusions. The description only lists what it returns without indicating usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pressuredesk_freshnessPressureDesk FreshnessARead-onlyIdempotentInspect
Return latest snapshot freshness state.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| kind | No | Machine-readable response kind, for example source-health, agent-home, or tool-buyer-dossier. |
| status | No | Readiness, payment, or request status when present. |
| product | No | Product name when the response is a public product or route packet. |
| decision | No | BUY / WAIT / AVOID decision packet when the tool evaluates a paid target. |
| trustPacket | No | Receipt, freshness, source, and safety-boundary information for agent spend decisions. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must convey behavioral traits. It implies a read-only operation, but does not disclose potential side effects, caching behavior, or authentication needs. For a simple getter, the transparency is minimal but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of five words, starting with the verb. Every word is necessary and front-loaded. No unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should explain what 'freshness state' entails. It does not, leaving the agent uncertain about the return format. However, the tool is simple with no parameters, so a minimal description may suffice. It is adequate but not fully 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 has zero parameters and 100% schema description coverage, so the baseline is 4. The description adds no parameter information, but none is needed.
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 'Return' and the resource 'latest snapshot freshness state,' which is specific and distinct from sibling tools like 'pressuredesk_preview_latest' or 'pressuredesk_source_health'. Despite the brevity, the purpose is unambiguous.
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 no guidance on when to use this tool versus alternatives, nor does it mention any prerequisites or context. It simply states what the tool does without any usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pressuredesk_get_dossierGet Signal DossierCRead-onlyIdempotentInspect
Return the latest full dossier for one PressureDesk entity id.
| Name | Required | Description | Default |
|---|---|---|---|
| entityId | Yes | PressureDesk entity id to retrieve, such as a scored market or tool-buyer target id. |
Output Schema
| Name | Required | Description |
|---|---|---|
| kind | No | Machine-readable response kind, for example source-health, agent-home, or tool-buyer-dossier. |
| status | No | Readiness, payment, or request status when present. |
| product | No | Product name when the response is a public product or route packet. |
| decision | No | BUY / WAIT / AVOID decision packet when the tool evaluates a paid target. |
| trustPacket | No | Receipt, freshness, source, and safety-boundary information for agent spend decisions. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description must carry behavioral info. It implies a read operation but lacks details on authentication, rate limits, or what 'full dossier' entails.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence is concise and front-loaded, but could include more useful information without being wasteful. Currently under-informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description should explain return format or behavior. It does not, leaving agents guessing about what a 'dossier' contains.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%; description does not explain the entityId parameter (e.g., how to obtain it, format). Merely mentions 'one PressureDesk entity id' without 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 action (Return), the resource (latest full dossier), and the scope (for one entity id). It is specific but could better distinguish from sibling tools like pressuredesk_preview_latest.
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 (e.g., pressuredesk_preview_latest for previews). No context on prerequisites or ideal scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pressuredesk_live_payment_statusPressureDesk Live Payment StatusARead-onlyIdempotentInspect
Read the x402 and premium-entitlement readiness status without exposing secrets.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| kind | No | Machine-readable response kind, for example source-health, agent-home, or tool-buyer-dossier. |
| status | No | Readiness, payment, or request status when present. |
| product | No | Product name when the response is a public product or route packet. |
| decision | No | BUY / WAIT / AVOID decision packet when the tool evaluates a paid target. |
| trustPacket | No | Receipt, freshness, source, and safety-boundary information for agent spend decisions. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The only behavioral trait disclosed is that the tool operates 'without exposing secrets', implying a safety characteristic. No annotations are present, so the description carries the full burden, but it does not address idempotency, side effects, or result structure.
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 of 16 words. It is front-loaded with the action and resource, and every word is functional; there is no extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with no parameters and no output schema, but the description omits important details such as the meaning of 'x402' and the format of the returned status. It does not specify the response shape, making it incomplete for an agent to fully understand the tool's output.
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?
With zero parameters, the baseline score is 4. The description adds meaning by explaining what statuses are read, which is beyond the empty schema. However, it does not elaborate on the parameterless nature.
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 reads 'x402 and premium-entitlement readiness status', specifying both the action (Read) and the resource. It also adds a distinguishing feature ('without exposing secrets'), making its purpose distinct from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives such as 'pressuredesk_founding_access' or 'pressuredesk_freshness' is provided. The description does not list conditions, prerequisites, or when not to use it, leaving the AI agent without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pressuredesk_metaPressureDesk MetadataBRead-onlyIdempotentInspect
Return PressureDesk product metadata, routes, pricing, and latest snapshot id.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| kind | No | Machine-readable response kind, for example source-health, agent-home, or tool-buyer-dossier. |
| status | No | Readiness, payment, or request status when present. |
| product | No | Product name when the response is a public product or route packet. |
| decision | No | BUY / WAIT / AVOID decision packet when the tool evaluates a paid target. |
| trustPacket | No | Receipt, freshness, source, and safety-boundary information for agent spend decisions. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as read-only nature (though implied), permissions, rate limits, or any side effects. It simply states the output without 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 sentence of 9 words, front-loaded with the verb 'Return' and the resource. Every word adds value, and there is no fluff.
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 simplicity of the tool (no parameters, no output schema), the description is minimally adequate but could elaborate on what 'metadata' includes or the format of the returned data for completeness.
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 the input schema coverage is 100% (empty). According to guidelines, 0 parameters merits a baseline of 4. The description adds no param info, which is acceptable.
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 the tool returns product metadata, routes, pricing, and latest snapshot id, which is a specific verb-resource combination. It distinguishes from siblings like pressuredesk_get_dossier and pressuredesk_source_health, but the term 'metadata' is somewhat vague.
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. The description lacks any context about scenarios, prerequisites, or exclusions, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pressuredesk_preview_latestPreview Latest SnapshotARead-onlyIdempotentInspect
Return a redacted preview of the latest PressureDesk snapshot.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| kind | No | Machine-readable response kind, for example source-health, agent-home, or tool-buyer-dossier. |
| status | No | Readiness, payment, or request status when present. |
| product | No | Product name when the response is a public product or route packet. |
| decision | No | BUY / WAIT / AVOID decision packet when the tool evaluates a paid target. |
| trustPacket | No | Receipt, freshness, source, and safety-boundary information for agent spend decisions. |
Tool Definition Quality
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 mentions 'redacted preview' but does not explain what redaction entails, whether the snapshot is cached or real-time, or any side effects. The term 'latest' is ambiguous without a time reference.
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 quickly conveys the core functionality. However, additional context about the nature of 'redacted' or 'latest' could be added without losing conciseness.
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?
Despite being a simple parameterless tool, the description lacks completeness. It does not describe the return format, what 'redacted' means, or how 'latest' is determined. Additionally, it provides no guidance on how this tool relates to siblings like pressuredesk_source_health or pressuredesk_freshness.
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 no parameters (100% coverage). The description adds meaning by specifying that the output is a 'redacted preview of the latest snapshot', which compensates for the lack of 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 'Return' and the specific resource 'redacted preview of the latest PressureDesk snapshot'. It distinguishes itself from sibling tools like pressuredesk_get_dossier and pressuredesk_meta by focusing on a preview of the latest snapshot.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool over alternatives such as pressuredesk_get_dossier or pressuredesk_freshness. The description implies it is for a quick, redacted preview, but does not specify scenarios or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pressuredesk_source_healthPressureDesk Source HealthBRead-onlyIdempotentInspect
Return source provenance, source mode, freshness, trust reasons, and adapter errors.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| kind | No | Machine-readable response kind, for example source-health, agent-home, or tool-buyer-dossier. |
| status | No | Readiness, payment, or request status when present. |
| product | No | Product name when the response is a public product or route packet. |
| decision | No | BUY / WAIT / AVOID decision packet when the tool evaluates a paid target. |
| trustPacket | No | Receipt, freshness, source, and safety-boundary information for agent spend decisions. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It only says 'Return' implying read-only, but lacks details on side effects, authentication needs, or rate limits. Minimal disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no fluff. Could be slightly more structured but efficient for the information conveyed.
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?
Lists returned fields but leaves ambiguity about terms like 'source provenance' and 'trust reasons'. With no output schema, more context would help. Adequate but not fully self-contained.
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?
No parameters in input schema, so schema coverage is 100%. The description doesn't need to add parameter info, aligning with baseline 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 lists specific data items returned (source provenance, mode, freshness, trust reasons, adapter errors), clearly indicating the tool's function. However, the verb 'Return' is vague and could be more active like 'Retrieve health status'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus siblings like 'pressuredesk_freshness'. The description does not mention context, prerequisites, or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!