Tollmint
Server Details
Per-call data for agents: graded behavioural science, dark-pattern detection, web fetch, geocode.
- 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 4/5 across 14 of 14 tools scored. Lowest: 3.4/5.
Each tool has a clearly distinct purpose. The psychology tools are well-separated (biases, cognitive load, dark patterns, etc.), and even similarly named tools like psych_dark-pattern-detect and psych_dark-patterns serve different functions (scanning vs. taxonomy). No overlap causes confusion.
Tool names follow a clear pattern with domain prefixes and underscores, but hyphens appear in some compound names (e.g., content_ai-score, design_ai-slop-detect, psych_cognitive-load), creating minor inconsistency. Overall pattern is still predictable.
14 tools is a reasonable count for a multi-domain service. Each tool is specialized and earns its place, though the set covers a broad range of topics (content, design, psychology, geocoding, web). Not excessive or too thin.
The psychology domain is well-covered with tools for biases, dark patterns, enforcement, effects, heuristics, and trust signals. Content and design have one tool each, which seems adequate. The only missing piece might be a reverse geocode or additional design-related tools, but overall coverage is good.
Available Tools
14 toolscontent_ai-scoreAInspect
Measure how mechanically a piece of text reads across 19 stylistic signals: sentence-length variance (burstiness), em-dash rate, negative parallelism, copula avoidance, the characteristic AI vocabulary cluster, hedged superlatives, significance inflation, puffery, vague attribution, over-signposting, formatting tics, and more. Returns a per-sentence breakdown naming which signal each one tripped. Deterministic and model-free, so before-and-after comparisons across an edit are meaningful. NOT an AI detector — it reports stylistic properties, never authorship, and returns no verdict or probability. Authorship classifiers are unreliable and disproportionately misjudge non-native English writers. Costs $0.004000 per call.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | ||
| include_sentences | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It discloses deterministic behavior, model-free nature, cost per call, and the output structure (per-sentence breakdown). It does not discuss auth or rate limits, but the provided details are extensive.
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 lengthy but every sentence adds value, front-loading the main purpose. It could be slightly more concise, but it remains efficient given the number of signals listed.
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 2 parameters, no output schema, and no annotations, the description provides a good overview but lacks parameter documentation. The per-sentence breakdown is mentioned but the exact output format is not specified.
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%, and the description does not describe the parameters 'text' or 'include_sentences' beyond the tool's purpose. The default value of 'include_sentences' is not mentioned, and maxLength/minLength for 'text' are not explained.
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 measures mechanicalness across 19 stylistic signals, provides a per-sentence breakdown, and explicitly distinguishes itself from sibling tools like 'design_ai-slop-detect' by clarifying it is not an AI detector.
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 explains it is deterministic and model-free, making before-and-after comparisons meaningful, and explicitly states it is not an AI detector. However, it does not directly guide when to use this tool versus its siblings beyond the 'not an AI detector' distinction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
design_ai-slop-detectAInspect
Score how closely a page matches the documented 2025-2026 AI/template design fingerprint: the Tailwind indigo-violet gradient, a default sans with no display pairing, the badge/hero/three-card/steps/testimonial/pricing skeleton, glassmorphism, uniform border radii, emoji feature bullets, round-number social proof with no attribution, and abstract illustration in place of the product. Each finding quotes the markup that produced it and names the move that breaks the pattern. Deterministic and model-free. Reports template convergence, never authorship — the same fingerprint appears in human sites built from the same tutorials. Costs $0.025000 per call.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | Page to analyse. Fetched respecting robots.txt. | |
| html | No | Raw HTML, if you already have it. Takes precedence over url. | |
| fail_above_score | No | Set a verdict of "fail" above this score. Useful for gating a design review in CI. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description provides good behavioral context: it is deterministic, model-free, reports template convergence not authorship, and states cost. However, it does not explain error handling or precedence when both url and html are provided.
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 front-loaded with the purpose and is informative, though somewhat dense. It could be slightly more concise, but all sentences add value.
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 lack of output schema, the description adequately explains what the tool returns (findings with quotes and moves). It covers complexity well, including cost and behavior.
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 schema already describes each parameter. The description adds no additional semantics beyond the schema, meeting the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: scoring a page against a specific AI/template design fingerprint. It lists concrete design elements and distinguishes itself from siblings by focusing on template detection.
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, nor any mention of when not to use it. The context for usage is implied but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
psych_biasesAInspect
Cognitive biases with their mechanism, the conditions that trigger them, documented countermeasures, and an exploitation-risk score. Every entry carries its citation and replication status. Use to audit a decision process, to harden a system against manipulation, or to check your own reasoning. Costs $0.001500 per call.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| domain | No | ||
| offset | No | ||
| search | No | ||
| actionable_only | No | Exclude effects that failed replication. Defaults true — countering a non-existent bias wastes effort. | |
| replication_status | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the cost ($0.001500 per call) and mentions that every entry includes citation and replication status. It implies a read-only, informational tool without destructive side effects. However, it does not discuss rate limits or pagination behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loading what the tool returns and then providing usage guidance and cost. There is no wasted text, though it could be slightly more 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?
With no output schema and moderate complexity (6 parameters, filtering, pagination), the description does not fully explain return structure or how search/domain filtering works. It mentions cost and result fields, but pagination and response format are missing, making it adequate but incomplete.
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 only 17% (only actionable_only has a description). The tool description does not mention any parameters like limit, domain, offset, search, or replication_status. Since coverage is low, the description should compensate but fails to do so, leaving agents without guidance on how to filter or paginate.
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 the tool provides cognitive biases with mechanism, conditions, countermeasures, exploitation-risk score, citation, and replication status. It specifies use cases: auditing decision processes, hardening systems against manipulation, and checking reasoning. This distinguishes it from sibling tools like psych_cognitive-load or psych_dark-pattern-detect.
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 states usage: 'Use to audit a decision process, to harden a system against manipulation, or to check your own reasoning.' However, it does not explicitly mention when not to use the tool or suggest alternatives, though sibling tools are provided in context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
psych_cognitive-loadAInspect
Measure the mental effort a page demands before a decision can be made: form fields, competing choices, interactive density, and reading burden. Deterministic and reproducible — the same markup always scores the same, so the number is usable for tracking a page over time or against a competitor. Choice count is weighted logarithmically per Hick's law rather than linearly, which is the law's most common misapplication. Costs $0.025000 per call.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | Page to analyse. Fetched respecting robots.txt. | |
| html | No | Raw HTML, if you already have it. Takes precedence over url. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses deterministic behavior ('same markup always scores the same'), the algorithm (Hick's law weighting), and cost ($0.025 per call). This is good transparency, though it could add details about side effects or authentication needs.
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, with four sentences that cover purpose, determinism, algorithm, and cost. No wasted words; well-structured and front-loaded.
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 2 parameters, no output schema, and no annotations. The description explains what it measures and how it works, but does not describe the return value format or structure. For a measurement tool, this omission reduces 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?
Schema coverage is 100% with clear descriptions for url and html. The tool description adds no additional parameter meaning beyond what the schema provides. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a clear verb and resource: 'Measure the mental effort a page demands before a decision can be made', and lists specific factors (form fields, choices, density, reading burden). It distinguishes itself from sibling psychology tools by focusing on cognitive load measurement.
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 context (e.g., deterministic, for tracking over time) but does not explicitly state when to use this tool versus alternatives like psych_biases or psych_dark-pattern-detect. No exclusions or alternative guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
psych_dark-pattern-detectAInspect
Scan a live page or raw HTML for deceptive design. Returns each detected pattern with the evidence quoted from the markup, the regulation it trips, and the honest alternative. Fully deterministic — no model call, so results are reproducible and the same page always scores the same. Returns a clean/review/fail verdict suitable for gating a deploy. Names the patterns that need a full user flow to assess rather than implying the site is clean. Costs $0.030000 per call.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | Page to analyse. Fetched respecting robots.txt. | |
| html | No | Raw HTML, if you already have it. Takes precedence over url. | |
| jurisdiction | No | Filter findings to a jurisdiction, e.g. "EU" or "US". Omit for all. | |
| fail_above_severity | No | Sets verdict to "fail" when any pattern meets or exceeds this severity. Useful in CI. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses critical behavioral traits: it is fully deterministic ('no model call'), reproducible, costs $0.03 per call, and returns a clean/review/fail verdict. It also notes that patterns requiring full user flow are identified. However, it does not mention any limitations such as static-only analysis or error handling, which are not covered by annotations (none provided).
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 that front-loads the main purpose and efficiently covers key details like determinism, cost, and verdict. It is slightly verbose but every sentence adds value.
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 lack of an output schema and the tool's moderate complexity, the description covers essential aspects: input sources, output (patterns with evidence/regulation/alternative), verdict, and cost. It mentions needing full user flow for some patterns. However, it does not describe error conditions or the exact format of returned data.
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 baseline is 3. The description adds context by explaining the verdict system and the overall function, but it does not enhance the understanding of individual parameters beyond what the schema already provides.
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: 'Scan a live page or raw HTML for deceptive design.' It specifies the action (scan), the resource (page/HTML), and the outcome (detect deceptive patterns with evidence, regulation, and alternative). This distinguishes it well from siblings like 'psych_biases' or 'content_ai-score'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through features like deterministic results and cost, but it does not explicitly state when to use this tool versus its sibling 'psych_dark-patterns' or other alternatives. It mentions verdicts suitable for deployment gating but lacks direct guidance on when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
psych_dark-patternsBInspect
Deceptive-design taxonomy with the regulation each pattern trips (EU DSA Art. 25, UCPD, FTC ROSCA and the Negative Option Rule), the signals that detect it in markup or copy, a severity score, and the honest alternative that achieves the same business goal. Use before shipping conversion changes, or to audit a competitor. Costs $0.002000 per call.
| Name | Required | Description | Default |
|---|---|---|---|
| search | No | ||
| category | No | ||
| jurisdiction | No | Filter to patterns regulated in a jurisdiction, e.g. "EU" or "US" | |
| min_severity | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It discloses cost but does not explicitly state read-only nature or other behavioral traits like rate limits. The cost disclosure adds transparency, but overall behavioral detail is limited.
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 sentences: first summarizes content, second provides usage, third states cost. Information is front-loaded and relevant, though slightly verbose in the first sentence. 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 no output schema, the description partially explains returned data (regulations, signals, severity, alternative) but lacks format or structure details. It is sufficient for a lookup tool but not comprehensive.
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 low (25%, only jurisdiction described). The description does not explain the search, category, or min_severity parameters. It adds context about signals and severity but fails to clarify parameter usage, so it insufficiently compensates for the schema gap.
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 is a 'deceptive-design taxonomy' and lists what it includes (regulations, signals, severity, alternatives), giving a specific purpose. It lacks a single verb but effectively conveys the tool's function as a reference resource.
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 concrete usage scenarios: 'Use before shipping conversion changes, or to audit a competitor.' This clearly indicates when to use, though it does not explicitly exclude alternatives or mention when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
psych_effectsAInspect
Query a curated corpus of behavioural science effects. Every entry carries its canonical citation, replication status (robust / mixed / contested / failed), effect size, and boundary conditions. Effects that failed replication are included and labelled, not hidden — filter with actionable_only to exclude them. Costs $0.001000 per call.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| domain | No | ||
| offset | No | ||
| search | No | ||
| actionable_only | No | Return only effects safe to act on without human review (robust and mixed) | |
| replication_status | No | ||
| max_manipulation_baseline | No | Exclude effects whose inherent manipulation risk exceeds this threshold |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the burden of behavioral disclosure. It mentions the cost per call, the inclusion of failed replications, and the data fields returned, which gives a good sense of behavior. However, it does not explicitly state that the tool is read-only or idempotent, although that is implied by its query nature.
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 at three sentences, front-loading the core purpose, then adding key details about data and filtering, and finishing with cost. Every sentence adds value without unnecessary 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 the tool has 7 parameters, no output schema, and no annotations, the description leaves many aspects unclear. It does not explain pagination (offset/limit), the meaning of domain and search, or the replication_status filter. The return format is also omitted, making the description incomplete for an agent to fully understand usage.
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 7 parameters with only 29% description coverage, meaning 5 parameters lack descriptions. The tool description only elaborates on actionable_only, leaving domain, search, limit, offset, replication_status, and max_manipulation_baseline unexplained. This is insufficient compensation for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool queries a corpus of behavioral science effects and lists the data each entry carries (citation, replication status, effect size, boundary conditions). This differentiates it from sibling tools like psych_biases or psych_heuristics, making the purpose unmistakable.
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 explains that failed replications are included and can be excluded using the actionable_only filter, providing clear usage context. However, it does not explicitly state when to avoid this tool or mention alternatives among siblings, slightly reducing guidance completeness.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
psych_enforcementAInspect
Regulatory enforcement actions over deceptive interface design, each citing the regulator’s own document: the law and article, the company, the penalty, and what was actually on the screen. Includes dismissals, vacated rules and findings of lawfulness, which mark where the line sits and which fine-only lists omit. Also reports patterns prohibited but never enforced, and cases excluded for want of a primary source. Use to tell whether a design choice has cost anyone money, and where. Costs $0.004000 per call.
| Name | Required | Description | Default |
|---|---|---|---|
| outcome | No | ||
| pattern | No | Pattern to look up. Accepts our taxonomy ids (roach-motel, fake-urgency, hidden-costs, trick-wording, forced-continuity) or enforcement terms (drip-pricing, preselected-consent, obstruction, privacy-zuckering, bait-and-switch, disguised-ads). | |
| min_penalty | No | Minimum penalty in the record currency. Rows with no penalty are excluded. | |
| jurisdiction | No | Substring match: "EU", "UK", "US-federal", "US-state", "France", "India". | |
| boundary_only | No | Return only outcomes that bound the rule — dismissals, vacated rules, findings of lawfulness. These say what is permitted, which fines cannot. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It effectively discloses that the tool includes dismissals, vacated rules, findings of lawfulness, patterns never enforced, and excluded cases. This informs the agent about the data scope and boundaries, though it could mention it is a read-only operation.
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 informative and front-loaded with the tool's purpose, but it is somewhat verbose. Each sentence adds value, but it could be more concise without losing essential 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 no output schema, the description explains what the tool returns (law, article, company, penalty, screen content) and covers edge cases (dismissals, patterns never enforced). This provides sufficient context for an agent to understand the tool's output, though a structured output spec would be ideal.
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 80%, so the schema already documents most parameters well. The tool description adds general context but does not improve understanding of individual parameters beyond what is in the schema. The baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves regulatory enforcement actions for deceptive interface design, specifying what each entry includes (law, article, company, penalty, screen content). It distinguishes from sibling tools like 'psych_dark-pattern-detect' by focusing on enforcement outcomes rather than detection.
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 states 'Use to tell whether a design choice has cost anyone money, and where,' providing a clear use case. It also mentions cost per call. However, it does not specify when not to use this tool or direct to alternatives among the listed siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
psych_heuristicsAInspect
Interaction-design laws with their formulae, sources, and design implications — Fitts, Hick, Jakob, Tesler, Doherty. Includes the common misapplications, since these are misquoted more often than they are wrong. Separate from the effects corpus because these are engineering constraints, not contested empirical claims. Costs $0.001000 per call.
| Name | Required | Description | Default |
|---|---|---|---|
| search | No | ||
| with_formula | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses cost ($0.001000 per call) and that it includes formulae, sources, and misapplications. However, it does not explicitly state if the tool is read-only, any side effects, or authentication requirements.
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, reasonably concise. It front-loads the core purpose and adds context efficiently, though could be slightly more 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?
Given two optional parameters and no output schema, the description covers the content (laws, formulae, sources, implications, misapplications) but does not explain return format or pagination. It is minimally complete for a simple lookup 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?
Schema description coverage is 0%, and the tool description does not explain the 'search' or 'with_formula' parameters. The mention of 'formulae' vaguely relates to 'with_formula', but no clear mapping is given. The description fails to add meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as covering Interaction-design laws (Fitts, Hick, Jakob, Tesler, Doherty) with formulae, sources, and design implications. It explicitly distinguishes itself from the sibling 'psych_effects' by noting these are engineering constraints, not contested empirical claims.
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 separates the tool from 'psych_effects' and mentions inclusion of common misapplications, providing context on when to use it. However, it does not explicitly state when not to use it or name alternatives beyond 'psych_effects'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
psych_trust-signalsAInspect
Check which trust signals a page carries and which it omits — pricing visibility, privacy and terms, contact routes, cancellation terms. Each gap is returned with the inference a visitor draws from its absence, because under ambiguity aversion missing information is read as adverse rather than neutral: a hidden price is inferred to be a high one. Deterministic, model-free, and reproducible. Costs $0.025000 per call.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | Page to analyse. Fetched respecting robots.txt. | |
| html | No | Raw HTML, if you already have it. Takes precedence over url. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden and discloses determinism, model-free reproducibility, respect for robots.txt, cost, and the inference from ambiguity aversion. It lacks details on error handling or output format but is largely transparent.
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 that front-loads the main purpose, then efficiently details signals, reasoning, and behavioral notes. Every sentence adds value with no 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 no output schema, the description explains that each gap is returned with an inference, but does not specify exact output structure. However, for a simple checklist tool, this is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. The tool description adds value by noting robots.txt respect for url and precedence of html over url, providing behavioral context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks which trust signals a page carries and which it omits, listing specific signals (pricing visibility, privacy and terms, contact routes, cancellation terms). This distinguishes it from sibling tools like psych_biases or psych_dark-pattern-detect, which address different psychological aspects.
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 use when assessing trust signals on a page through context, but does not explicitly state when not to use or provide alternatives. However, the distinct focus on trust signals among siblings provides clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ref_geocodeAInspect
Convert a free-form address or place name into coordinates with normalised address components, a calibrated confidence score, and precision classification (rooftop / street / locality / region / country). Deduplicates OSM elements and flags ambiguous queries with the competing alternatives. Data from OpenStreetMap. Costs $0.000800 per call.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | Free-form address or place name | |
| country_codes | No | ISO 3166-1 alpha-2 codes to restrict the search |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses data source (OpenStreetMap), cost per call ($0.000800), deduplication of OSM elements, and ambiguity flagging. However, it does not mention auth, rate limits, or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core action and output, then additional features. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, so description adequately explains output components (coordinates, address components, confidence, precision classification). Covers deduplication and ambiguity. Misses error cases and pagination, but overall sufficient for 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 has 3 parameters with 67% description coverage. The description restates the purpose of the 'query' parameter but adds no new semantics. It does not explain 'limit' or 'country_codes' beyond the schema 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?
Description clearly states the tool converts a free-form address or place name into coordinates with normalized components, confidence score, and precision classification. It also mentions deduplication and ambiguity handling, making the purpose specific and 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?
The description implies usage for geocoding addresses and mentions cost and data source, but lacks explicit guidance on when to use vs. alternatives or when not to use. Sibling tools are in different domains, so the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tollmint_catalogAInspect
List every Tollmint product with its price, sourcing class, evidence grading, latency SLO and input schema. Free — this call costs nothing. Call it first to see what is available and what it costs.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 adds valuable behavioral info: 'Free — this call costs nothing,' and lists the return fields. This is sufficient for a read-only catalog 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?
Two sentences total. The first sentence front-loads the purpose and output fields. The second adds cost and strategic advice. 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?
Despite no output schema, the description explicitly names the return fields (price, sourcing class, evidence grading, latency SLO, input schema). Combined with zero parameters, the description fully informs 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 tool has zero parameters, so baseline is 4. The description adds no parameter info as none exist, but doesn't detract.
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') and names the resource ('Tollmint products') along with the specific fields returned. It clearly distinguishes from siblings like 'tollmint_quote' which likely handles quoting.
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 'Call it first to see what is available and what it costs,' providing clear when-to-use guidance. It does not explicitly list alternatives or when-not-to-use, but the context implies it's a discovery tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tollmint_quoteAInspect
Get the exact price of a specific call before making it. Free — this call costs nothing. The quoted price is binding: you will never be charged more than it.
| Name | Required | Description | Default |
|---|---|---|---|
| input | No | The input you intend to send | |
| product | Yes | Product id, e.g. "psych/effects" |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that the call is free and the price is binding, but does not address authentication, rate limits, or side effects. The behavioral traits are partially covered but not comprehensively.
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, concise and front-loaded with the primary purpose. Every sentence adds value: first defines action, second clarifies cost and binding nature. 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 no output schema, the description should explain what the tool returns. It mentions 'exact price' and 'quoted price' but does not specify format or additional fields. For a simple tool this is adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline is 3. The description does not add any parameter-specific information beyond what the schema already provides (e.g., input is described as 'the input you intend to send' in both places). No enrichment.
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: 'Get the exact price of a specific call before making it.' This specifies a verb (get), a resource (price of a call), and a context (before making the call), distinguishing it from siblings like tollmint_catalog which likely lists products.
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 when to use ('before making it') and notes that it's free, but does not explicitly state when not to use or provide alternatives. The sibling list does not include another pricing tool, so the guidance is sufficient for context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
web_fetchAInspect
Fetch a URL and return the main content as clean markdown, with navigation, cookie banners, footers, and related-post chrome removed. Extracts title, byline, publication date, and excerpt. Content detection is driven by link density rather than class names, so it survives CSS refactors. Reports how much of the page was retained and whether it had to fall back to the full body, so you can tell a clean extraction from a guess. Honours robots.txt; refuses private addresses and pages behind authentication. Costs $0.003000 per call.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | Page to analyse. Fetched respecting robots.txt. | |
| html | No | Raw HTML, if you already have it. Takes precedence over url. | |
| max_words | No | Truncate the markdown at this many words. Truncation is reported. | |
| include_links | No | Keep inline links as markdown. Disable to cut tokens when only prose matters. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses extraction method (link density), fallback behavior, what content is removed (navigation, banners, etc.), and reports retention stats. Also mentions honoring robots.txt and refusing private/auth pages. No annotations present, so description fully carries transparency burden.
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 well-organized sentences, front-loaded with core purpose. Each sentence adds unique value (purpose, detection method, restrictions/cost). Slightly long but efficient; 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?
Covers input parameters, output contents, extraction approach, restrictions, and pricing. Lacks return format details or error states, but given no output schema, the description provides adequate context for a content-extraction 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?
Adds context beyond schema: url's robots.txt compliance, max_words truncation reporting, include_links token reduction hint. Schema already provides descriptions for all 4 parameters, but description enriches usage semantics for each.
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 'Fetch a URL and return the main content as clean markdown' with specific verb and resource. It distinguishes from sibling tools (mostly psych/design analysis) by focusing on web content extraction and cleanup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for extracting clean content from web pages but does not explicitly state when to use or provide comparisons to alternatives. Mentions restrictions (robots.txt, private addresses) but lacks explicit guidance on context or exclusions.
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!