Zero-config agent-readiness auditor and Flight Simulator tools for AI coding agents
Scored across 5 tools
Each tool has a clearly distinct purpose: audit runs a full evaluation, discover_surfaces finds entrypoints, get_score returns a compact result, get_skill fetches documentation, and simulate_flight runs a simulator. No two tools could be easily confused.
All tools share the glintbase_ prefix and follow a verb_noun pattern (audit, discover_surfaces, get_score, get_skill, simulate_flight). The naming is uniform and predictable.
Five tools is well-scoped for an agent-readiness auditing server. Each tool covers a distinct workflow stage without unnecessary bloat or missing core capabilities.
The set covers the full audit lifecycle: surface discovery, full audit, score retrieval, and simulator. A minor gap is the lack of a list operation for available skills or surfaces, but agents can work around this with the documented skill names.
Execute full ARS 3.0 agent-readiness audit on a target URL. Evaluates Discovery, Access, Usability, Semantic, Architecture, and Safety across 119 discrete open protocol checks.
| 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 readOnlyHint, idempotentHint, and non-destructive behavior. The description adds meaningful behavioral context by specifying what the audit actually evaluates (Discovery, Access, Usability, Semantic, Architecture, Safety) and the scope (119 checks), going beyond the structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with no filler. The core action is front-loaded, and the second sentence efficiently expands on scope without repeating the tool name or schema 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?
For a single-parameter audit tool with an output schema, the description is largely complete: it explains the purpose, scope, and evaluation dimensions. The only gap is the lack of explicit guidance on when to choose this tool over its siblings, which is a modest omission given the tool's clear name and scope.
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 only parameter, 'target', is already described as 'Target URL to audit'. The description redundantly says 'target URL' but adds no new semantic detail 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 names a specific verb ('Execute'), a clearly defined resource ('full ARS 3.0 agent-readiness audit'), and a target ('a target URL'). It also enumerates the six evaluation dimensions, making the tool's purpose concrete and distinguishing it from the 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?
Usage context is implied by the word 'full' and the mention of '119 discrete open protocol checks', which suggests this is the comprehensive audit tool rather than a narrower sibling like glintbase_get_score or glintbase_simulate_flight. However, it never explicitly names alternatives or states when not to use this tool.
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.0 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 cover safety (readOnly, idempotent, non-destructive). The description adds behavioral context about output size ('<200 tokens') and efficiency ('without burning agent context'), which is useful beyond the annotations. It does not contradict annotations, and the additional info is relevant and accurate.
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, well-structured sentence that front-loads the primary action and characteristic, then provides a use case. It contains no fluff or redundant information, making it highly concise and effective.
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 tool with a complete input schema, an output schema, and safety annotations, the description fully covers what an agent needs to decide to use it and call it correctly. The token budget and use-case hints add necessary context without gaps.
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 fully describes the only parameter (target) with 100% coverage. The description adds no extra meaning about the parameter (e.g., format, validation, examples) beyond what the schema provides. Since coverage is high, baseline 3 is appropriate; the description doesn't need to compensate.
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 fetches an 'ARS 3.0 score card' with a specific verb and resource, and adds the key characteristic of being 'ultra-compact' (<200 tokens). It does not explicitly name or contrast with sibling tools like glintbase_audit, but the purpose is specific and unambiguous, so it earns a 4 rather than 5.
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 use contexts: 'Ideal for quick checks and CI status monitoring without burning agent context.' This tells the agent when to use it, but it does not explicitly mention alternatives or when not to use it. Still, the guidance is clear and actionable, warranting a 4.
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.