Zero-config agent-readiness auditor and Flight Simulator tools for AI coding agents
Scored across 5 tools
Each tool has a recognizable role: full audit, discovery probe, compact score, skill retrieval, and simulation. The main friction is between glintbase_audit and glintbase_get_score (both surface a score) and between glintbase_audit and glintbase_discover_surfaces, since discovery is described as a sub-probe of the audit; descriptions mitigate this by clarifying full-run vs. compact-fetch vs. focused-probe.
All five tools share a uniform glintbase_ snake_case prefix with verb-led names (discover_surfaces, get_score, get_skill, simulate_flight). glintbase_audit is a bare verb without a noun, a minor deviation, but the overall pattern is predictable and readable.
Five tools is a tight, well-scoped surface where each entry corresponds to a distinct workflow step (audit, discover, quick score, learn, simulate). No tool feels redundant or like filler.
The agent-readiness domain is covered end to end: probing, scoring, quick status checks, guidance playbooks, and simulated validation. Minor gaps exist — no batch/multi-URL auditing, no historical score comparison, and no remediation/fix action after an audit finds issues.
Execute a full ARS 3.3 agent-readiness audit on a target URL. Probes Discovery, Access, Usability and Payments; checks that cannot be verified are reported as skipped and excluded from the score.
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | Target URL to audit (e.g. "https://docs.stripe.com") |
| Name | Required | Description |
|---|---|---|
| grade | Yes | |
| score | Yes | |
| layers | Yes | |
| target | Yes | |
| archetype | No | |
| totalChecks | No | |
| passedChecks | No | |
| remediations | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds genuine behavioral context the annotations don't: unverifiable checks are reported as skipped and excluded from the score, which tells the agent how to interpret partial results. It does not mention runtime cost or expected result shape, hence not a 5.
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, zero filler. The action and target are front-loaded, and the skipped-checks caveat follows immediately as the one non-obvious fact.
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 a single documented parameter, full annotation coverage, and an output schema to explain returns, the definition is nearly complete. The only unaddressed gap is that 'ARS 3.3' is unexplained jargon and the audit's likely duration/expense is not signaled.
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?
Only one parameter, and its schema entry already defines it at 100% coverage with an example URL. The description adds no format, scope, or constraint detail beyond the schema, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Execute') and resource ('full ARS 3.3 agent-readiness audit on a target URL') plus the four probe domains. It is clearly a broader, whole-site audit than a surface listing or score lookup, though it never names a sibling to contrast against.
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 word 'full' implies this is the comprehensive option versus narrower siblings like glintbase_discover_surfaces or glintbase_get_score, but the description never states when to choose this over them or any preconditions. Usage is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Discover machine-readable entrypoints (robots.txt, llms.txt, ard.json, auth.md, OpenAPI, sitemap). Probes availability, syntax, and compliance.
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | Target URL to inspect (e.g. "https://docs.stripe.com") |
| Name | Required | Description |
|---|---|---|
| target | Yes | |
| summary | No | |
| surfaces | Yes | |
| totalSurfaceTypes | No | |
| discoveredSurfacesCount | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds meaningful behavioral context by stating it 'probes availability, syntax, and compliance' and listing the specific file types it checks. This goes beyond the annotation's safety profile without contradicting it.
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?
One sentence with zero filler. The primary action is front-loaded ('Discover machine-readable entrypoints'), followed by a compact parenthetical list and a summary of checks. Every phrase earns its place.
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 a single parameter, an output schema, and read-only annotations, the description covers what the tool does and what it checks. It could mention that the target should be a base URL or that only standard entrypoints are checked, but those are minor gaps given the simple context and existing structured 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?
The input schema already fully documents the single 'target' parameter with an example URL, achieving 100% coverage. The description adds no additional parameter-level guidance (e.g., base URL format, trailing slash behavior), so it provides no extra semantic value beyond 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 uses specific verbs ('Discover', 'Probes') and names a concrete resource list (robots.txt, llms.txt, ard.json, auth.md, OpenAPI, sitemap). It clearly distinguishes from siblings like glintbase_audit and glintbase_get_score, as this is the only tool about entrypoint discovery.
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 no guidance on when to use this tool versus its siblings. It does not state that it should be called before an audit, nor does it mention any exclusions or prerequisites. The user must infer use cases from the tool name and sibling context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch ultra-compact ARS 3.3 score card (<200 tokens). Ideal for quick checks and CI status monitoring without burning agent context.
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | Target URL to evaluate (e.g. "https://docs.github.com") |
| Name | Required | Description |
|---|---|---|
| grade | Yes | |
| score | Yes | |
| layers | Yes | |
| target | Yes | |
| archetype | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds meaningful behavioral context by stating the output is ultra-compact (<200 tokens) and intended to avoid burning agent 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 two compact sentences with the core action and token-size constraint front-loaded. Every phrase adds useful selection or context information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple one-parameter, read-only tool with annotations covering safety and an output schema covering return values. The description supplies the remaining relevant context: compact output size and CI/quick-check suitability.
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%, and the single required target parameter is already fully documented in the schema. The description does not add format or validation details beyond the schema, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: "Fetch ultra-compact ARS 3.3 score card." It is clear enough to distinguish a lightweight score fetch from broader audit work, but it does not explicitly name a sibling alternative such as glintbase_audit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase "Ideal for quick checks and CI status monitoring" gives implied usage context. However, it does not state when not to use this tool or explicitly compare it with glintbase_audit or other siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve full markdown skill playbook for agent readiness (e.g. "agent-readiness", "living-artifacts-architect", "agent-auth-handbook", "mcp-server-hardening").
| Name | Required | Description | Default |
|---|---|---|---|
| skillName | Yes | Skill name or query (e.g. "agent-readiness", "living-artifacts", "auth", "mcp") |
| Name | Required | Description |
|---|---|---|
| uri | No | |
| skill | Yes | |
| title | Yes | |
| content | Yes | |
| description | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds the useful detail that the result is a 'full markdown playbook', but does not go beyond that to mention behavior such as error conditions, matching semantics, or fallbacks. With annotations carrying the core behavioral burden, this is a solid but not exceptional score.
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 one sentence with zero filler, and the purpose is front-loaded. The examples are useful and directly support parameter understanding without bloating the text.
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 single-parameter read-only tool with an output schema and complete annotation safety hints, the description adequately covers what the agent needs to call it correctly. It could optionally enumerate all available skill names, but the examples are sufficient for normal use and close siblings are already distinct.
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%, and the schema already explains the 'skillName' parameter with examples. The description repeats examples but does not add meaning beyond the schema. Per the baseline rule for high schema coverage, a 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 ('Retrieve') and names the resource ('full markdown skill playbook'), with concrete examples of valid skill names. It clearly distinguishes itself from sibling tools like glintbase_audit or glintbase_get_score, 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 provides clear context: this is the tool to retrieve a skill playbook for agent readiness. While it does not explicitly name sibling alternatives or when-not-to-use conditions, the examples and verb make the intended usage obvious and distinct from the other glintbase tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run the Glintbase Agent Flight Simulator across synthetic coding personas. Returns multi-modal output with a visual Journey Tree graphic, telemetry, and replay link.
| Name | Required | Description | Default |
|---|---|---|---|
| intent | No | User intent to simulate (e.g. "Find API reference and create an API key") | |
| target | Yes | Target URL to simulate (e.g. "https://stripe.com") | |
| persona | No | Agent persona (default: claude-code) |
| Name | Required | Description |
|---|---|---|
| target | Yes | |
| outcome | Yes | |
| persona | No | |
| success | Yes | |
| replayUrl | Yes | |
| totalHops | No | |
| failureBottleneck | No | |
| totalTokensBurned | Yes | |
| schemaFrictionScore | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the read-only, idempotent, non-destructive nature of the tool. The description adds useful behavioral context by stating the return type is multi-modal and includes a Journey Tree graphic, telemetry, and replay link.
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, no filler. The action and scope are front-loaded, and the output details are concise and relevant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity, complete schema coverage, presence of an output schema, and safety annotations, the description is sufficient. An agent has everything needed to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents all parameters adequately. The description adds no additional parameter-level details, which matches the baseline for high 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 names a specific verb and resource ('Run the Glintbase Agent Flight Simulator') and summarizes the output. It clearly distinguishes itself from sibling tools by focusing on simulation, though it does not explicitly contrast itself with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case: simulating a target URL across synthetic coding personas glintbase. However, it provides no explicit guidance on when to choose this tool over siblings like glintbase_audit or glintbase_discover_surfaces.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
glintbase_auditglintbase_discover_surfacesglintbase_get_scoreglintbase_get_skillglintbase_simulate_flight
Add one secure layer between your agents and this server.