Real-world tasks in Hamburg: quote, check service area, submit an enquiry for human review.
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 4.3/5 across 5 of 5 tools scored.
Most tools have clearly distinct purposes, but get_use_cases and list_capabilities both describe service offerings, creating mild ambiguity about which to call. check_service_area and quote_task also overlap slightly on eligibility checks.
All tool names follow a consistent verb_noun snake_case pattern (check_, get_, list_, quote_, submit_), making the set highly predictable and readable.
Five tools is well within the ideal range and each covers a distinct step in the enquiry workflow, from eligibility check to submission, without unnecessary bloat.
The enquiry lifecycle is well covered: eligibility, capabilities, examples, quoting, and submission. However, there is no tool to track or manage a submitted enquiry, which is a minor gap.
check_service_areaCheck the service areaACheck whether an address or district is inside the service area, without describing a task. Use this for a fast yes/no before planning anything.
| Name | Required | Description | Default |
|---|---|---|---|
| location | Yes | Address, postal code or district. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already indicates a safe read operation. The description adds behavioral context beyond that: it states the tool performs a fast yes/no check, clarifying the nature and scope of the response. It does not contradict the annotation.
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 action and purpose, and contains no redundant information. Every word earns its place, making it highly concise and well-structured.
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 read-only tool with one parameter and no output schema, the description is adequate: it explains the purpose, input, and use case. It implies the output is a yes/no result, which is sufficient. It does not delve into edge cases or error handling, but these are not critical for such a simple 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 schema description covers 100% of the single parameter 'location' with 'Address, postal code or district.' The tool description adds no new details about the parameter beyond that, so it relies on the schema, earning a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: checking whether an address or district is inside the service area. It uses a specific verb ('check') and resource ('service area'), and distinguishes it from siblings like quote_task and submit_request by focusing on the pre-planning eligibility check.
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 explicitly says to use the tool 'for a fast yes/no before planning anything,' providing clear context for when to use it. It does not explicitly name alternatives or exclusion criteria, but the phrasing implies it is not for detailed planning or task descriptions, which differentiates it from sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_use_casesGet example tasksAConcrete examples of tasks that have been defined for this service, plus the boundaries of what is knowingly not accepted. These are illustrations, not open listings — nothing here is available to claim.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false. The description adds meaningful behavioral context beyond those hints: results are curated, non-exhaustive illustrations, and the tool also exposes boundaries of what is knowingly not accepted. No contradiction with annotations.
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 tight sentences: the first front-loads the core purpose, the second adds the critical caveat that results are illustrative and non-claimable. Every word earns its place with no redundant filler.
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 zero-parameter, read-only informational tool with no output schema, the description adequately covers what the agent receives (task examples and rejection boundaries) and how to interpret it (illustrations, not open listings). It does not specify response format, but the simplicity of the tool keeps this gap minor.
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 schema coverage is trivially 100% and the baseline of 4 applies. There is nothing for the description to explain about parameters, and it appropriately omits 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 title ('Get example tasks') plus description ('Concrete examples of tasks that have been defined for this service') states a specific verb and resource with clear scope. It distinguishes from siblings by declaring these are 'illustrations, not open listings — nothing here is available to claim,' separating it from claim/submission-oriented tools like submit_request.
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 for when to use the tool: to view illustrative examples and understand acceptance boundaries. 'Nothing here is available to claim' implies a when-not (don't treat results as claimable submissions), though no sibling alternative is explicitly named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_capabilitiesList capabilitiesAList every task type this service performs, with evidence returned, price range and turnaround. Call this first when you do not know what can be requested.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds useful context about the content returned (evidence, price, turnaround), but does not disclose potential pagination or ordering behaviors. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no wasted words. The first sentence states the primary function and output fields; the second provides usage guidance. Excellent front-loading.
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 zero-parameter, read-only listing tool, the description is complete: it states what is returned, when to use it, and implies it is a discovery entry point. It could mention potential service-area constraints, but those are covered by sibling tools.
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 does not need to explain parameters, and there is no schema ambiguity to resolve.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List every task type') and identifies the resource ('this service performs') with concrete output fields (evidence, price range, turnaround). It is clear and distinct from quote_task or submit_request, though it does not explicitly differentiate from the sibling get_use_cases.
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 guidance: 'Call this first when you do not know what can be requested.' This provides a clear context for use, but it does not mention when not to use it or describe alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
quote_taskQuote a real-world taskAEstimate feasibility, price range, turnaround and evidence for a described task. Instant, deterministic and free of side effects: it creates nothing, reserves nothing and contacts nobody. A task outside the service area is rejected immediately.
| Name | Required | Description | Default |
|---|---|---|---|
| task | Yes | What should happen on site, in plain language. | |
| delivery | No | Restrict matching to on-site work (someone travels to a place) or remote work (someone tests software from wherever they are). Inferred from the description when omitted. | |
| evidence | No | Evidence the requester wants back. | |
| location | No | Address or district. Only used for on-site work, to confirm the service area. Ignored for remote work. | |
| locations | No | Number of locations, for capabilities priced per location. | |
| capability | No | Optional capability id from `list_capabilities`; inferred from the text otherwise. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond the readOnlyHint annotation by explicitly stating 'creates nothing, reserves nothing and contacts nobody,' and adds determinism and instant behavior. It also discloses that out-of-area tasks are rejected, which helps set expectations. No contradiction with annotations.
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?
Three concise sentences, front-loaded with purpose and outputs. Each sentence adds distinct value: what it does, side-effect guarantees, and edge-case rejection. No filler or repetition of schema details.
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 six parameters, rich schema descriptions, annotations, and the absence of an output schema, the description covers purpose, behavior, and rejection conditions. It does not describe the return value shape, but since it explicitly lists what is estimated, the overall context is sufficient for an agent to decide and invoke it 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?
Schema description coverage is 100%, so the input schema already documents all six parameters thoroughly. The description adds little beyond naming 'evidence' as part of the estimation output and 'service area' as a possible rejection reason, which is marginal value. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Estimate') and resource ('a described task'), and lists concrete outputs: feasibility, price range, turnaround, and evidence. This clearly distinguishes it from sibling tools like submit_request and check_service_area, making the purpose 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 intended use is implied by the title and description—estimate a quote for a task—but there is no explicit statement of when to use this tool versus alternatives, such as 'use submit_request to place the actual task' or 'use check_service_area to verify coverage.' The rejection note hints at service-area constraints but doesn't guide tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
submit_requestSubmit a request for human reviewAQueue an enquiry for a human to review. This is NOT an order and does NOT create a task: no operator is contacted until a person has reviewed it. Only call this after the user has explicitly agreed to send an enquiry, and only with contact details the user provided. Requires consent: true.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | Address the answer is sent to. | ||
| source | No | How the requester found this service. | |
| company | No | Organisation on whose behalf the request is made. | |
| consent | Yes | Must be true. Confirms the user agreed to be contacted about this request. | |
| deadline | No | Free text or ISO date. | |
| evidence | No | Evidence the requester wants back. | |
| location | Yes | Address in the service area. | |
| budgetEur | No | Budget ceiling in euro. | |
| locations | No | ||
| capability | No | Capability id, if already known from a quote. | |
| contactName | Yes | Name of the person making the request. | |
| idempotencyKey | No | Stable key so a retry cannot queue the same request twice. | |
| taskDescription | Yes | What should happen on site, including anything a reviewer needs to judge it. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds meaningful behavioral context beyond the annotations: it clarifies that no operator is contacted until a human reviews the enquiry, and that consent:true is required. This goes beyond the idempotentHint and openWorldHint annotations and helps the agent understand the side effects and prerequisites.
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. It front-loads the main purpose, then provides key behavioral exclusions and usage prerequisites. Every sentence carries important information without waste.
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's moderate complexity (13 params, no output schema, no nested objects), the description covers the core behavioral contract, usage conditions, and consent requirement. It provides enough context for an agent to use the tool correctly without needing to know return values. The safety-relevant information is fully disclosed.
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 high (92%), so the baseline is 3. The description adds semantic value by emphasizing that consent must be true and that contact details must come from the user, which clarifies the intended meaning of several parameters (contactName, email, location). This lifts it to a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Queue') and clearly names the resource ('an enquiry for a human to review'). It explicitly distinguishes itself from an order or task, which differentiates it from sibling tools like quote_task or get_use_cases.
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 states clear usage conditions: only after the user explicitly agrees, and only with contact details the user provided. It also explicitly says what this tool does NOT do (does not create a task, no operator contacted until review), providing strong when-to-use vs. alternatives guidance.
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!