Check that your AI is being logical. Free tool that mathematically catches contradictions in agent reasoning. No account needed. Also offers paid guardrails that converts natural language to formal verification proofs, that anyone can check succinctly.
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 14 of 14 tools scored.
Each tool has a distinct role, but the presence of payment-method variants (check_action vs check_action_paid, create_account vs create_account_card, top_up vs top_up_card) introduces minor overlap that is clearly explained. The check tools are differentiated by output detail and purpose, though quick_check and check_action could be confused at a glance.
Names predominantly follow a verb_noun pattern (check_action, create_account, run_tests), with consistent _paid and _card suffixes for payment variants. Minor deviations like quick_check (adjective_noun) and top_up (phrasal verb) are understandable but break the pattern slightly.
With 14 tools, the set covers the full lifecycle of policy creation, testing, action checking, payment, and proof verification without bloat. Each tool serves a clear purpose within the service's scope.
The primary workflow (create policy, test policy, check actions, verify proofs) is well covered, including multiple payment options. Missing utilities like listing or deleting policies and credit balance checks are minor gaps that don't block the core use case.
check_actionAInspectEnforce a guardrail: verify an agent action against a compiled policy using formal verification. An SMT solver — not an LLM — determines whether the action satisfies every rule. Returns SAT (allowed) or UNSAT (blocked) with extracted values and a cryptographic ZK proof that the check was performed correctly. Cannot be jailbroken. 1 credit ($0.01). Requires api_key. Tip: end the action with an explicit claim like 'I assert this complies with the policy' for best extraction.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | The agent action to verify against the policy (max 2000 chars) | |
| api_key | Yes | Your ICME API key | |
| policy_id | Yes | Policy ID from make_rules |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses key behaviors: uses SMT solver, returns SAT/UNSAT with extracted values and ZK proof, cannot be jailbroken, costs 1 credit, and requires api_key. This significantly exceeds typical transparency and gives the agent a precise model of what to expect.
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?
Most sentences earn their place, covering core purpose, mechanics, output, cost, and a usage tip. It's slightly choppy with short sentences, but it is still front-loaded and free of 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 there is no output schema, the description explains the return values (SAT/UNSAT, extracted values, ZK proof), the verification guarantee, cost, auth requirement, and even a tip for better results. For a tool of this complexity, this is highly 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%, so parameters are already documented. The description adds value by explaining that policy_id comes from make_rules, and the tip about ending the action with an explicit claim enriches the 'action' parameter semantics beyond the basic description.
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 verifies an agent action against a policy using formal verification. It distinguishes itself from siblings by emphasizing the SMT solver (not an LLM) and the 'cannot be jailbroken' property, making its unique value proposition explicit.
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 a clear use context ('Enforce a guardrail') and prerequisites (api_key, 1 credit). However, it doesn't explicitly mention when not to use it or name alternatives, so it stops short of full exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_action_paidAInspectSame formal verification as check_action, but pay per call with x402 ($0.10 USDC on Base) instead of using credits. No API key or account needed — any agent with a wallet can verify actions on the fly. Returns SAT (allowed) or UNSAT (blocked) with extracted values and optional ZK proof.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | The agent action to verify against the policy (max 2000 chars) | |
| policy_id | Yes | Policy ID from make_rules |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the burden. It discloses the payment amount and method, the absence of account requirements, and the return format including optional ZK proof. It doesn't disclose potential failures or side effects, but verification implies non-mutating.
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 high information density, front-loading the relationship to check_action and covering cost, authentication, and output.
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 2-parameter verification tool without output schema, the description fully covers the key aspects: payment, return type, and optional proof. The reference to check_action provides additional 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?
Input schema has 100% coverage with descriptive parameter texts, so the description doesn't need to add much. It also doesn't add parameter-specific details 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's function: formal verification of actions, similar to check_action, with the key differentiator of x402 payment. It specifies the output (SAT/UNSAT) and distinguishes it from siblings by payment method.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly compares to check_action, indicating this is for paying per call with x402 instead of credits, and notes no API key or account needed. It implies usage when the agent has a wallet and wants on-the-fly verification, but doesn't provide explicit when-not-to-use scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_logicAInspectCatch contradictions in reasoning before acting on it. FREE — no account needed. Extracts quantitative and logical claims from any plan, calculation, or chain of thought, then uses a Z3 SAT solver to mathematically prove whether they contradict each other. This is formal verification, not an LLM second-guessing itself. Returns CONSISTENT, CONTRADICTION, or UNKNOWN with the extracted claims.
| Name | Required | Description | Default |
|---|---|---|---|
| show_smt | No | Include the generated SMT-LIB2 formula in the response for inspection (default: false) | |
| reasoning | Yes | The reasoning, plan, or chain of thought to check. Be specific — include numbers, conditions, and constraints for the best results (max 2000 chars) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility and excels: it states the tool is free, requires no account, uses a Z3 SAT solver for mathematical proof, and returns specific outcomes (CONSISTENT, CONTRADICTION, UNKNOWN) with extracted claims. It also clarifies that it is not an LLM re-check, providing important behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each earning its place: a clear action-oriented first sentence, a method explanation, and an output clarification. It is front-loaded and free of filler, making it easy to scan.
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 (one required string param) and the description fully covers purpose, method, outputs, and prerequisites. It explains the return values, which is particularly helpful since no output schema exists. The 2000-char limit is in the schema, so it need not be repeated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds contextual examples ('include numbers, conditions, and constraints') but this largely echoes the schema's own guidance. It does not deepen the semantics of show_smt beyond its schema description, so no extra credit is warranted.
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: 'Catch contradictions in reasoning before acting on it.' It specifies the resource (reasoning/plan/calculation) and the method (Z3 SAT solver), and distinguishes it from sibling tools like check_action or check_relevance by focusing on logical consistency rather than action verification or relevance.
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 usage context: 'before acting on it' and 'any plan, calculation, or chain of thought.' It also clarifies that this is formal verification, not LLM self-review, which helps agents decide when to use it. However, it does not explicitly name alternatives or exclusion cases, so it stops short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_relevanceAInspectFree relevance screen — checks whether an action touches any of your policy variables before running a paid check. Returns a relevance score and which variables matched. If should_check is true, run check_action. If false, the action is unrelated to your policy — skip the paid check. No credits charged. Requires api_key.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | The agent action to screen (max 2000 chars) | |
| api_key | Yes | Your ICME API key | |
| policy_id | Yes | Policy ID from make_rules | |
| threshold | No | Relevance threshold (0.0 to 1.0). Default 0.0 — any match triggers should_check. Optional. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses cost (free, no credits charged), outputs (relevance score, matched variables, should_check flag), and conditional behavior (next steps based on should_check). It does not mention error handling or side effects, but for a screening tool, the disclosed traits are substantial.
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 compact and front-loaded with the key hook ('Free relevance screen'). Each sentence earns its place: purpose, return value, conditional guidance, cost indication, and auth requirement. No fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explains return values (score, matched variables) and the should_check flag meaning. It also covers cost and integration with check_action. Missing details like error responses or rate limits, but for the tool's simplicity and with full schema coverage, it is nearly 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%, so baseline is 3. The description reiterates api_key and the should_check logic, but adds minimal new meaning about parameters themselves. It does not explain action, policy_id, or threshold beyond the schema descriptions, so it does not elevate beyond 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: a free relevance screen that checks policy variables before a paid check. It uses a specific verb ('checks') and resource ('policy variables'), and distinguishes itself from siblings like check_action and check_action_paid by explicitly positioning it as the preliminary step.
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?
Explicitly instructs when to use it: before running a paid check. It provides conditional guidance based on should_check, telling the agent to run check_action if true and skip the paid check if false. This clearly differentiates from alternative tools and gives actionable usage rules.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_accountAInspectCreate an ICME Preflight account with x402 USDC payment ($5.00 on Base). Returns an API key and 325 starting credits immediately. Save the api_key — it is shown only once. Use create_account_card instead if paying by credit card.
| Name | Required | Description | Default |
|---|---|---|---|
| username | Yes | Unique username (1-32 chars, alphanumeric + hyphens/underscores) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description compensates well by disclosing the payment requirement ($5.00), immediate credits, and the one-time display of the API key. It falls short of detailing failure modes or post-creation side effects, but covers the most critical behaviors for a creation 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?
Three sentences, each earning its place: purpose, output/behavior, and alternative. Front-loaded with the primary action and no 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?
For a simple create tool with one parameter, the description covers purpose, payment, immediate output, a critical caveat (API key shown once), and alternative tools. Without an output schema, it still communicates the return values effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides a complete description for the single parameter (username) with pattern and length constraints. The description adds no additional parameter-level detail, but given 100% schema coverage, a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Create') and clearly identifies the resource (ICME Preflight account), including payment method and immediate output. It explicitly distinguishes itself from sibling tool create_account_card by directing credit card payments there.
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 explicit guidance on when to use this tool (paying with x402 USDC) and names the alternative (create_account_card) for credit card payments. This is direct and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_account_cardAInspectCreate an ICME Preflight account with a credit card ($5.00 via Stripe). Returns a checkout_url — open it in a browser to pay. After payment completes, call poll_session with the session_id to retrieve your API key.
| Name | Required | Description | Default |
|---|---|---|---|
| username | Yes | Unique username (1-32 chars, alphanumeric + hyphens/underscores) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the payment flow, return value (checkout_url), and the follow-up step, which is valuable behavioral context beyond 'create account'. It doesn't mention failure modes or permission requirements, but the core behavior is 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 two sentences, front-loaded with the core purpose and cost, then the follow-up procedure. Every sentence adds necessary information with no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one parameter, no output schema, and no annotations. The description explains the full flow including the returned checkout_url and the next step (poll_session), which is sufficient for an agent to use it correctly. Minor gaps like error handling or specific failure behavior are not critical for this 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 input schema has 100% coverage for the single parameter 'username' with a clear description. The tool description adds no additional parameter information, so the schema is sufficient and 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 'Create an ICME Preflight account with a credit card' which is a specific verb and resource. It distinguishes from sibling 'create_account' by specifying payment method and cost, making the tool's unique 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 description gives explicit context: returns checkout_url, instructs to open in browser, and directs to call poll_session with session_id after payment. Though it doesn't explicitly say when not to use it, the sequence and prerequisites are clear enough for an agent to know when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_scenariosAInspectReview auto-generated test scenarios for a compiled policy. Shows example actions that should pass and fail, so you can verify the policy behaves as intended before deploying it. Requires api_key.
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | Yes | Your ICME API key | |
| policy_id | Yes | Policy ID from make_rules |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. The word 'Review' and 'Shows' indicate a read-only operation, and the phrase 'before deploying it' implies non-destructive verification. It also notes the prerequisite that the policy must be compiled. It does not disclose potential side effects or limitations, but the read-only nature is strongly implied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the primary purpose. The first sentence states the core function, the second explains the value, and the redundant note about api_key is minimal. Every sentence contributes to understanding without unnecessary 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?
There is no output schema, so the description must convey what the tool returns. It does so by stating that it 'Shows example actions that should pass and fail,' which gives a clear idea of the output type. It also provides enough context for use. Minor gaps include not describing the output format in more detail, but it is sufficient for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for both parameters (api_key and policy_id), so the schema already provides full meaning. The description only restates that api_key is required, adding no new parameter semantics. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Review auto-generated test scenarios for a compiled policy.' It uses a specific verb ('review'), identifies the resource ('test scenarios'), and adds detail ('Shows example actions that should pass and fail'). This distinguishes it from siblings like run_tests and check_action, which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use the tool: 'so you can verify the policy behaves as intended before deploying it.' However, it does not explicitly mention alternatives or provide exclusion criteria, which would merit a 5. The context is clear enough to guide appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
make_rulesAInspectTurn a plain-English policy into a jailbreak-proof guardrail. Write rules the way you would explain them to a colleague — ICME compiles them into formal logic (SMT-LIB) that a mathematical solver enforces. No prompt engineering. No LLM judges. The solver either proves an action complies or it doesn't. Returns a policy_id and test scenarios for review. Costs 300 credits. Requires api_key.
| Name | Required | Description | Default |
|---|---|---|---|
| policy | Yes | Your policy in plain English, e.g. 'No action may access user data without explicit consent. External API calls require approval above $100.' Up to 50 rules. | |
| api_key | Yes | Your ICME API key (from create_account or create_account_card) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals that the policy is compiled into SMT-LIB logic enforced by a mathematical solver, that it is deterministic ('The solver either proves an action complies or it doesn't'), and that it costs 300 credits and requires an api_key. It also states the return value (policy_id and test scenarios). This is substantial behavioral context, though it does not mention potential timeouts, rate limits, or failure modes.
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 four sentences, front-loaded with the core purpose. Every sentence adds value: purpose, mechanism, contrast with alternatives, and output/cost/requirement. There is no redundancy or fluff, 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?
Even though there is no output schema and no annotations, the description covers the essential context: what the tool does, how it works, what it returns, and the cost. It explains the return value (policy_id and test scenarios) and the deterministic nature. It does not specify whether the operation is synchronous or asynchronous, which could be relevant given the sibling poll_session, but overall it is sufficiently complete for a rule-creation 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 100%, so the baseline is 3. The description adds minimal parameter-specific detail: it repeats the need for an api_key and gives a general instruction ('Write rules the way you would explain them to a colleague'), but the schema already explains the 'policy' parameter with examples and limits. Thus, the description only marginally enhances parameter understanding.
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: 'Turn a plain-English policy into a jailbreak-proof guardrail.' It uses a specific verb ('turn') and identifies the resource (policy) and the outcome (guardrail). It distinguishes itself from sibling tools like check_action and check_logic, which are for evaluating actions rather than creating rules. The mention of 'Returns a policy_id and test scenarios' further clarifies the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: when you have a plain-English policy and need to enforce it as a formal guardrail. It contrasts with typical LLM-based approaches by stating 'No prompt engineering. No LLM judges,' implying it is for deterministic enforcement. However, it does not explicitly name alternative tools or state when not to use it, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
poll_sessionAInspectCheck the status of a Stripe card payment. Returns pending or complete. On completion after signup, returns the api_key. Call this after create_account_card or top_up_card once the user has paid.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | The session_id returned by create_account_card or top_up_card |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It states that the tool is a status check ('Check the status') and describes the return values ('pending or complete', 'api_key on completion after signup'). However, it omits potential error behavior, authentication requirements, or whether it can be called repeatedly. This is adequate, not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action, and every sentence contributes value. It is highly concise without padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter polling tool, the description is quite complete. It tells what it returns (pending/complete and api_key on completion after signup) and when to call it. However, it does not cover error cases (e.g., invalid session_id) or whether there are side effects, which prevents a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description for session_id already states it is 'The session_id returned by create_account_card or top_up_card', and the tool description repeats this. With 100% schema coverage, baseline is 3; the description adds no additional 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 states the specific purpose: 'Check the status of a Stripe card payment. Returns pending or complete.' It also adds a distinguishing detail by mentioning the return of api_key on completion after signup. This distinguishes it from sibling tools like check_action or quick_check, which likely serve different purposes.
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 explicit usage context: 'Call this after create_account_card or top_up_card once the user has paid.' This tells when to use the tool, with clear prerequisites. It does not explicitly mention alternatives or when not to use it, so it falls short of a 5, but the context is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
quick_checkAInspectFast yes/no guardrail verdict — returns only ALLOWED or BLOCKED with no proof details. Use when you need a lightweight gate and don't need the full SAT/UNSAT report or ZK proof. Same formal verification under the hood, just a minimal response. 1 credit. Requires api_key.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | The agent action to check (max 2000 chars) | |
| api_key | Yes | Your ICME API key | |
| policy_id | Yes | Policy ID from make_rules |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses that the response omits proof details, that it uses the same formal verification under the hood, and mentions credit cost and api_key requirement. It could add more about error behavior or response format beyond ALLOWED/BLOCKED, but the key behavioral trait—minimal response—is clearly disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is five sentences and front-loaded with the core purpose ('Fast yes/no guardrail verdict'). Each sentence adds value: minimal response, use cases, same verification, credit cost, and key requirement. 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 tool has 3 required params, 100% schema coverage, no output schema, and no annotations, the description competently fills gaps: it clarifies the minimal response type, cost, and alternative. It lacks an explicit output schema but the 'returns only ALLOWED or BLOCKED' statement effectively covers the return format. Slight deduction for not mentioning pagination or error cases, but 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 input schema already covers 100% of parameters with descriptions, so the baseline is 3. The description adds minimal parameter value beyond the schema, but it mentions 'action' as the agent action to check and 'policy_id' from make_rules, which reinforces the schema. No extra syntax or constraints are added.
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 ('returns') and resource ('yes/no guardrail verdict') while clearly distinguishing itself from siblings that return full SAT/UNSAT reports or ZK proof. It explicitly states the minimal response type (ALLOWED/BLOCKED), 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?
It explicitly states when to use: 'Use when you need a lightweight gate and don't need the full SAT/UNSAT report or ZK proof.' It also contrasts with the alternative (full report tools) and specifies a cost (1 credit) and auth requirement, guiding invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
run_testsAInspectRun saved test cases against a policy to confirm it blocks what it should block and allows what it should allow. Run this after make_rules and before using the policy in production. Requires api_key.
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | Yes | Your ICME API key | |
| policy_id | Yes | Policy ID to test |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It discloses the auth requirement ('Requires api_key') and the intended behavior (confirming block/allow logic). However, it does not detail side effects, whether the operation is read-only, or what happens on failure, leaving some ambiguity for a testing 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?
Three concise sentences: first defines purpose, second gives workflow placement, third states the auth requirement. Every sentence carries useful information with no redundancy, and the most critical information is 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?
For a simple tool with two parameters and no output schema, the description covers purpose, usage timing, and auth. It does not mention return values or error conditions, but the 'confirm it blocks/allows' wording implies the test results. This is reasonably complete given the tool's simplicity, though additional detail on response format would make it 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 already provides full descriptions for both parameters (policy_id and api_key) with 100% coverage. The description only repeats the api_key requirement without adding additional meaning, such as format specifics or how to obtain the key, so it does not exceed the baseline for schema-covered parameters.
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: 'Run saved test cases against a policy to confirm it blocks what it should block and allows what it should allow.' This specifies the verb, resource, and expected outcome, distinguishing it from siblings like make_rules (rule creation) and check_action (single action checking).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit sequencing: 'Run this after make_rules and before using the policy in production.' This gives clear context for when to use the tool, though it does not name alternative tools or exclusion criteria. The prerequisite 'Requires api_key' further guides usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
top_upAInspectAdd 500 credits to your account via x402 USDC payment ($5.00 on Base). Use top_up_card instead for credit card payment with volume discounts. Requires api_key.
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | Yes | Your ICME API key |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosure. It reveals the cost ($5.00), payment network (Base), payment method (x402 USDC), and required api_key. While it doesn't mention failure handling or reversibility, the disclosure is adequate for a simple top-up 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 two sentences with no fluff. It front-loads the primary purpose, gives an alternative, and states the requirement. Every sentence 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 tool with one parameter, no output schema, and no annotations, the description covers purpose, payment method, cost, alternative, and requirement. It lacks mention of response format or success confirmation, but given the simplicity, it is sufficiently 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 schema has 100% coverage for the sole api_key parameter, describing it as 'Your ICME API key'. The tool description only repeats 'Requires api_key' without adding additional meaning, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action: 'Add 500 credits to your account via x402 USDC payment', which clearly identifies the verb, resource, and method. It also distinguishes itself from the sibling tool top_up_card by explicitly mentioning the USDC payment method.
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 provides an alternative: 'Use top_up_card instead for credit card payment with volume discounts.' This gives clear when-to-use guidance and excludes the main alternative, which is exactly what the dimension asks for.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
top_up_cardAInspectAdd credits via credit card with volume bonuses. Returns a checkout_url. Tiers: $5 = 500 credits, $10 = 1,050 (+5%), $25 = 2,750 (+10%), $50 = 5,750 (+15%), $100 = 12,000 (+20%). Credits never expire. Requires api_key.
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | Yes | Your ICME API key | |
| amount_usd | Yes | Top-up amount in USD: 5, 10, 25, 50, or 100 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It discloses several key behaviors: volume bonuses, tier rewards, 'Returns a checkout_url,' 'Credits never expire,' and 'Requires api_key.' This provides a solid understanding of the tool's behavior beyond a simple 'add credits' statement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the primary action. The tier list is necessary detail and presented in a clear, scannable format. It avoids fluff, and 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 tool's simplicity (2 params, no output schema, no annotations), the description is quite complete. It explains the purpose, return value, bonus tiers, expiration policy, and authentication requirement. It lacks error-handling or post-payment expectations, but for a top-up tool, this is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers both parameters and their descriptions (100% coverage), so the baseline is 3. The description adds value by explaining the volume bonus structure (e.g., '$10 = 1,050 (+5%)'), which is not in the schema, and reiterates the api_key requirement. This enriches the meaning of the 'amount_usd' parameter.
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: 'Add credits via credit card with volume bonuses.' It specifies the payment method and the resource (credits), and the tier details further clarify the behavior. This distinguishes it from the sibling tool 'top_up', which likely handles a different payment method.
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 this tool (when adding credits via credit card) but does not explicitly mention alternatives or exclusions. For example, it doesn't say 'use this instead of top_up for card payments.' So usage guidance is present but implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
verify_proofAInspectIndependently verify a ZK proof from a prior check_action call. Confirms the guardrail check was performed correctly without re-running it — any third party or monitoring agent can verify in under one second. No additional cost. Wait a few minutes after the check for the proof to be generated. Single-use per proof.
| Name | Required | Description | Default |
|---|---|---|---|
| proof_id | Yes | The proof_id returned by a prior check_action or check_action_paid call |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully covers behavioral traits: verification is independent, takes under one second, has no additional cost, requires a waiting period, and is single-use. These details go well beyond basic purpose, giving the agent crucial operational 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 three sentences, front-loaded with the primary purpose, followed by essential usage details. Every sentence contributes value, with no redundancy or irrelevant content.
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 simple one-parameter design and lack of output schema, the description adequately covers purpose, usage, behavior, and parameter semantics. It does not explicitly state the return value (e.g., boolean), but the phrase 'Confirms the guardrail check was performed correctly' implies a confirmation result, which is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes proof_id as the UUID from a prior check_action/check_action_paid call, but the description adds important semantics: it must come from a prior check, is single-use, and proof generation requires a wait. This extends the schema's meaning.
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 specific function: 'Independently verify a ZK proof from a prior check_action call.' It uses a specific verb ('verify') and resource ('ZK proof'), and distinguishes from sibling tools by clarifying it confirms the check 'without re-running it'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance: use it after a check_action call, wait a few minutes for proof generation, and it is single-use per proof. It also clarifies that verification is independent and can be done by any third party, effectively excluding re-running the original check.
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!
