insideout-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.0.1
Disambiguation4/5
Most tools have clearly distinct purposes tied to specific workflow stages (e.g., convoopen vs convoreply vs tfgenerate). However, convostatus and convoinspect both provide session inspection and could cause confusion, as could tfruns vs tfstatus vs tflogs. Overall, the boundaries are clear with only minor overlap.
Naming Consistency4/5
Tool names follow a strong prefix convention (convo-, tf-, aws-, gcp-, stack-) combined with descriptive verbs or nouns (open, reply, inspect, status, generate, deploy, destroy, etc.). A few tools like help and submit_feedback break the pattern but are clearly scoped. The naming is largely consistent and predictable.
Tool Count4/5
With 24 tools, the server is on the higher end but justified by the comprehensive infrastructure lifecycle coverage (conversation, generation, deployment, inspection, monitoring, rollback, feedback). Each tool fills a specific role, though the inspector variants (singular vs batch, AWS vs GCP) add bulk. The count is appropriate for the domain.
Completeness5/5
The tool set covers the full lifecycle: start/continue conversation, generate Terraform, deploy, destroy, plan, drift check, inspect both AWS and GCP, view logs/status/runs/outputs, manage versions and rollbacks, and submit feedback. No obvious gaps are present; the workflow from design to deployment to monitoring to teardown is fully supported.
Average 4.6/5 across 24 of 24 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on March 31, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true (safe) and openWorldHint=true (outputs vary). The description adds value by explaining sensitive outputs are redacted, and clarifies default versus specific job_id retrieval, and lifecycle filtering.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a clear first sentence stating purpose, followed by important details on output content, default behavior, and parameter explanations. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a retrieval tool with 3 parameters and no output schema, the description covers purpose, output content (structured values, sensitive redaction), default and optional behaviors, and required session_id format. It could mention error cases (e.g., if no outputs exist) but is mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds meaning beyond the schema: it explains the default when job_id is omitted, the exact format of session_id including the token suffix, and common lifecycle values. This helps correct usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves Terraform outputs from a completed deployment, using a specific verb and resource. It does not explicitly differentiate from sibling tools like tfstatus or tfplan, but the purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context on when to use the tool (after a deploy), default behavior (latest successful deploy), optional filters (job_id, lifecycle), and a prerequisite (session_id from convoopen). It does not explicitly state when not to use it or list alternatives, but the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, so the description does not need to reiterate that. The description adds behavioral details: list newest first, shows statuses (draft/confirmed/applied), change summaries, and timestamps. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three effective sentences: the first states the primary action, the second details output, the third gives usage guidance, and the fourth notes the required parameter. No wasted words, front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the input schema provides detailed parameter documentation and annotations cover read-only and open-world hints, the description is fairly complete. It covers purpose, output content, ordering, and prerequisites. However, the lack of an output schema is not compensated, but this is acceptable for an open-world tool. Minor gap: no mention of pagination or limits.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the schema description for session_id is very detailed (pattern, format, token suffix warning). The tool description only adds a brief requote of the requirement and format, adding minimal value beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all stack versions for a session, ordered newest first, and specifies the data shown (version number, status, change summaries, timestamps). This is a specific verb-resource combination that is distinct from siblings like stackdiff (compare versions) and stackrollback (rollback).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool: to see design history, review changes between iterations, or find a version number to roll back to. It also mentions a prerequisite (session_id from convoopen). However, it does not mention when not to use it or contrast with alternatives, which would make it a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true. Description adds important behavioral details: the read-only nature is reinforced with 'INSPECTION' and 'List', and it specifies return content. Also notes the session_id must be passed exactly as returned, which is critical. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four well-organized sentences: bolded purpose, return fields, use cases, prerequisite. No redundant or vague phrasing. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
A simple read-only list tool with one parameter and no output schema. Description covers purpose, prerequisites, returned fields, and use cases. Could mention pagination or limits, but not necessary given simplicity and annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema description already thoroughly documents the session_id parameter (format, requirement to include token). The tool description adds only a brief mention of 'session_id from convoopen response', which does not significantly exceed schema detail. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Starts with 'INSPECTION: List all Terraform deployment runs for a session', clearly indicating the action and resource. Specifies returned fields (job IDs, statuses, types, timestamps), distinguishing from sibling tools like tflogs or tfstatus.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly lists use cases: view deployment history, find job IDs for log inspection, check success/failure. States prerequisite (session_id from convoopen). Does not explicitly mention when not to use or alternatives, but context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds behavioral context by detailing the four categories of return data (Components, Config, Pricing, Phase Indicators) and explaining phase indicators as part of workflow state. It does not introduce contradictions and provides meaningful insight beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear opening line, bullet-point details for each return category, and usage instructions. It is informative without being overly verbose. Minor improvements could be made by trimming redundant formatting, but overall it is efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description thoroughly explains the structure of the response (Components, Config, Pricing, Phase Indicators) and provides usage guidance. It covers all critical aspects for an inspection tool but does not include potential error scenarios or response format nuances, which is acceptable for a read-only tool with annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 adds value by explaining that session_id must come from convoopen and explicitly noting the token suffix requirement ('never strip it when summarizing'). For job_id, it clarifies optional usage. This context goes beyond the schema's pattern and description fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'View the current infrastructure stack for a session', using a specific verb (view) and resource (infrastructure stack). It provides detailed breakdown of what is returned (components, config, pricing, phase indicators), clearly distinguishing this tool from siblings like convoinspect or convoopen by focusing on the session's infrastructure design state.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes explicit usage examples: 'Use this tool when the user asks 'what is my current stack?', 'show my infrastructure', 'what have I selected?', or similar questions.' It also mentions the prerequisite of session_id from convoopen. However, it does not state when not to use this tool or list alternatives, keeping it from a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, indicating safe read. The description adds valuable context: 'Responses include hints with next_actions and related_tools.' This reveals response structure beyond the tool's safety, which is helpful for agent planning.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: three short sentences covering purpose, usage, sections, and response hints. It's front-loaded and every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter and no output schema, the description covers purpose, usage, parameter semantics, and response structure. Combined with annotations (readOnlyHint, openWorldHint), the tool is fully specified for agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter 'section', with a detailed description ('Optional section to focus the response...') already present in the schema. The description mentions sections but doesn't add semantic meaning beyond what the schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides workflow guidance for InsideOut infrastructure tools. It differentiates between a compact overview (no args) and detailed guides with specific sections (workflow, tools, examples, inspect). This distinguishes it from sibling operational tools like awsinspect or tfdeploy.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description tells when to use: 'Call help() for a compact overview, or help(section=...) for a detailed guide.' It also lists available sections. While it doesn't explicitly say when not to use, the context of sibling tools (all operational) makes its purpose clear. A minor improvement would be to mention it's for seeking guidance rather than performing actions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate read-only and open-world; description adds detail on return structure (component changes, pricing), default behavior, and session_id requirement. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-organized with clear sections. Could be slightly more concise but front-loaded with purpose and key constraints.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers output structure, edge cases (empty baseline, pending drafts), and parameter defaults. No output schema, so description sufficiently explains return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters, but description adds context: session_id must include token suffix, from/to_version defaults and usage. Adds value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it produces a 'Structured diff showing what would be deployed' and distinguishes it from other tools like tfplan by focusing on version comparison and deployment preview.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Describes when to use (to see deployment impact) and defaults for version arguments. Does not explicitly list alternatives but the context of sibling tools makes it clear this is for diffing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate non-destructive and potentially unexpected results. The description adds context on required fields, optional fields, categories, and initiator semantics, providing transparency beyond annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with headers, lists, and examples. It is concise but informative, with each section earning its place. Slightly long due to examples, but appropriate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters, 3 required, no output schema, the description covers all parameters, provides usage examples, and explains the initiator field. It is complete for a feedback tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds value by explaining the initiator field, providing examples, and noting default source. This goes beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool is for submitting feedback, bug reports, or feature requests to Luther Systems. It distinguishes itself from sibling tools, none of which are feedback-related.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool (for user feedback or agent-reported issues) and provides categories and initiator guidance. It lacks an explicit 'when not to use' but is otherwise thorough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint and openWorldHint, and the description adds behavioral details: same return format as convoreply, timeout specifics (default 50, max 55), and session_id importance. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise with clear structure: introductory sentence, usage trigger, then REQUIRES/OPTIONAL sections. Every sentence adds value, uses emoji and bold for emphasis. No wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers return format, timeout behavior, and session_id pattern. Lacks detail on error handling or timeout expiration, but given annotations and schema, it is reasonably complete for a recovery tool with 3 params and no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds significant meaning: explains session_id origin, message_id from timeout error, and timeout defaults. Provides context like 'For Cursor, use 50' that goes beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool waits for a pending response after a convoreply timeout, specifying the action and resource. It distinguishes from convoreply and other sibling tools by focusing on recovery after timeout.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to use this tool when convoreply returned a timeout error, and mentions it avoids resending messages. While it doesn't explicitly list when not to use it, the context is clear and prerequisites are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate openWorldHint, idempotentHint, and non-destructive. Description aligns by noting polling, timeout, and secure handling. It adds context beyond annotations: workflow prerequisite, credential handling, and subscription requirement. Could mention that the tool blocks until timeout or success, but the timeout parameter implies this.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with sections, emoji, and bullets. Front-loaded with core purpose. Slightly verbose in the workflow explanation but every sentence is informative. Could be trimmed slightly, but still effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters, no output schema, and a blocking poller, the description covers trigger conditions, required session_id, optional parameters, workflow steps, and security note. Missing explicit return values (e.g., what happens on success/timeout), but the output schema is absent and the tool's behavior is implied.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with parameter descriptions. The description reinforces the session_id format ('pass back EXACTLY... including the ?token=... suffix') and clarifies defaults and constraints for cloud and timeout. Adds value by explaining the suffix importance and the purpose of each parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Wait for the user to securely connect their cloud account and subscribe to Luther Systems.' It uses specific verbs ('await', 'polls') and identifies the resource ('cloud credentials'). The tool's purpose is distinct from siblings like tfdeploy or convoawait.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'when tfdeploy returns an auth_required, no_credentials, or credentials_expired error.' Provides a step-by-step workflow and an important negative instruction: 'Do NOT call this tool without first showing the connect URL to the user.' This leaves no ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructive and open-world behavior. Description adds details: long-running (15+ min), single-flight constraint, conflict response, credential flow with connect_url, and parameter effects. Does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections (workflow, purpose, notes, parameters, credential flow). Front-loads key info. Slightly lengthy but each sentence adds value; no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all essential aspects: workflow position, prerequisites, parameter details, error handling (conflict, credential flow), and references to sibling tools for monitoring. No output schema, but return behavior is described adequately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description adds extra context for each parameter (e.g., plan_id for preview-then-apply, sandbox for testing, ignore_drift for drift handling) and warns about session_id token suffix, improving usability beyond schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool deploys infrastructure by starting a Terraform job, positions it as Step 4 of 4, and distinguishes from siblings like tfplan and tflogs via workflow context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use (after generation, step 4), when-not-to (another job in flight), and alternatives (tfstatus, tflogs, credawait). Includes preview-then-apply workflow and force_new override guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare idempotentHint=true and destructiveHint=false. Description adds rich context: default response keeps code out of context, fallback inlines code on failure, and explains the need to wait for user confirmation before downloading. This significantly augments the annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with bold headings, emojis, and bullet points that make scanning easy. Front-loaded with workflow step and prerequisite. While verbose, every sentence adds value; minimal redundancy. Could trim a few details but overall effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (workflow step, prerequisites, dual modes, user interaction), the description covers all essential aspects: prerequisites, when to use, step-by-step workflow, error handling, fallback, and follow-up actions. No output schema exists, but the description clarifies default vs. fallback response behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% coverage with explicit descriptions for both parameters (session_id format, include_code behavior). Description reinforces critical details like not stripping the token suffix and the fallback use case. Even with high schema coverage, the description adds valuable operational context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb ('Generate Terraform files'), specific context ('from completed design'), and explicit workflow step (3 of 4). Differentiates from sibling tools like tfdeploy by stating it's the generation step. Includes explicit conditions for use (after convoreply returns terraform_ready=true).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states prerequisite (convoreply with terraform_ready=true), when NOT to call (before terraform_ready), and alternative fallback (include_code). Provides a step-by-step workflow including user interaction and error handling, leaving no ambiguity about when and how 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses read-only behavior (consistent with readOnlyHint annotation) and describes return content (full message history, metadata). Adds value beyond annotations by detailing the output structure and confirming no mutation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise, well-structured paragraphs. First paragraph defines purpose and output, second lists companion tools, third provides use case and safety note. Every sentence is purposeful; no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description adequately explains return values (message history, metadata). With only one parameter and clear annotations, the description covers purpose, usage, behavior, and parameter requirements completely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 reinforces the critical token suffix requirement and warns against stripping it, adding practical guidance beyond the schema's pattern and description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool views a session's conversation transcript and metadata. Lists specific outputs (full message history, workflow step, cloud, etc.) and distinguishes itself from siblings by naming companion tools (convostatus, tfruns, stackversions).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use (e.g., 'what did I say earlier?', retracing session state) and when not (it's read-only, never mutates). Names alternatives and complementary tools, providing clear context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (idempotentHint, destructiveHint false) are complemented by detailed behavior: copies config components, updates in-place if draft exists. No contradiction, and adds meaningful context beyond structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three clear sections: purpose, usage hint, and parameter requirements. It could be slightly more structured but remains efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
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), the description completely covers behavior, prerequisites, edge cases, and dependencies. No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds crucial details: version parameter suggests using stackversions, session_id parameter specifies exact format and warns against stripping the token suffix. This adds value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a draft by reverting to a previous version's config, specifying the verb 'reverting' and resource 'stack version'. It distinguishes from sibling tools like stackversions by focusing on rollback action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises to use stackversions first to find available versions, and notes the single-draft rule for updates. While it doesn't list when not to use, the guidance is clear and practical.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Reinforces annotations (idempotent, non-destructive) by stating it's read-only. Adds important behavioral details: returns job_id, single-flight constraint, force_new override. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with labeled sections (DRIFT CHECK, single-flight, requires, optional). Front-loaded with key purpose. Slightly verbose but every sentence adds value, so appropriate for complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all necessary information for a read-only drift check tool: prerequisites (session_id, prior deployment), behavior (single-flight, read-only), return (job_id), and how to get results (tflogs). No output schema, but description clearly mentions return value and next steps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, description adds significant context: session_id format requirement including token suffix, and force_new semantics (bypass guard, use when wedged). Goes well beyond schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it's a 'DRIFT CHECK: Run a read-only drift detection check' and clearly distinguishes from siblings like tfdeploy and tflogs by mentioning usage of tflogs for results and tfdeploy(ignore_drift=true) for proceeding after drift detection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear when-to-use context: after a deployment to check drift. Mentions single-flight constraint and when force_new is appropriate (when existing run is wedged). Could be more explicit about when not to use (e.g., if no prior deployment).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true and openWorldHint=true. The description confirms read-only behavior by stating it fetches temporary read-only credentials. It adds transparency about working after failed deploys, inspecting orphaned resources, and response tiers. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (prerequisite, main purpose, response tiers, supported services, metrics, billing, examples). It is front-loaded with the most important information. Every section earns its place without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters, many services, multiple response tiers, prerequisites, and no output schema), the description is fully complete. It explains response tiers, provides examples, notes IAM permissions, and covers edge cases like failed deploys. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds substantial meaning beyond the schema: details on session_id format, service examples, action types, filter examples, and behavior of detail/raw flags. This enriches the agent's understanding of each parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The title and description clearly state the tool inspects AWS infrastructure for a deployed project. It lists specific services and actions, and distinguishes itself from siblings like gcpinspect and awsinspect_batch by focusing on AWS and providing detailed usage context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states the prerequisite of a prior deployment attempt and recommends checking convostatus for hasDeployAttempt=true. It provides context for when to use, but does not explicitly mention when not to use or compare with alternatives like awsinspect_batch. However, the clear usage context and examples compensate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint and openWorldHint, the description details budgets (sub count, timeouts, concurrency cap, response cap), partial failure behavior, credential handling, and response format. This fully informs the agent of operational constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but well-structured with headings (BUDGETS, PARTIAL FAILURE, etc.) and front-loaded with the core purpose. Every section adds necessary detail, though some redundancy could be trimmed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (batch, partial failure, multiple services), the description covers prerequisites, budgets, error handling, response format, and provides multiple examples. Without an output schema, this level of detail is essential and sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers all parameters (session_id, subs) with descriptions. The description adds value by providing examples, clarifying the subs structure (service, action, filters), and explaining the credential fan-out. Since schema coverage is 100%, baseline is 3, but the additional context raises it to 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it runs up to 32 AWS inspect probes in one batch call. The title 'Batch-Inspect AWS Infrastructure' reinforces the purpose. It distinguishes from sibling 'awsinspect' by emphasizing batching for efficiency.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises using this tool when checking more than ~3 resources, and directs to awsinspect for discovery or detailed output. It also states the prerequisite (deploy attempt required) and checks convostatus for hasDeployAttempt=true.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds significant behavioral context beyond destructiveHint annotation: describes long-running job, single-flight behavior, error type (tf_job_conflict), and post-completion state change (hasDeployment set to false). No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections, front-loaded key points. Slightly verbose in explaining single-flight and force_new, but each sentence adds value. Could be slightly tighter, but highly effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately covers behavior, prerequisites, and post-destroy state. Mentions monitoring tools. Missing return details but compensated by job monitoring references.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds critical meaning beyond schema: explains session_id format importance (including token), and force_new usage scenario (wedged runs). With 100% schema coverage, the description enriches parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool destroys infrastructure with the verb 'Destroy' and 'Tear down', specifying the resource as 'previously deployed infrastructure'. Differentiates from sibling tools like tfdeploy (deploy) and tfplan (plan).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit usage conditions: requires a prior successful deployment, a session_id from convoopen, and notes single-flight constraint. Provides guidance on handling conflicts (force_new, attaching to existing job) and monitoring with tfstatus/tflogs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that it returns job status without streaming logs, and provides detailed explanation of response timestamps (updated_at for semantic changes, last_refresh_at for oracle decode). This adds significant context beyond the readOnlyHint and openWorldHint annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with 'MONITORING' label and concise main purpose. Includes a detailed 'LIVENESS' section that adds value but adds length. Overall, every sentence contributes to clarity, though it could be slightly shorter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately explains return values (job status, job_id, metadata, timestamps). It covers required session_id, optional job_id, and how to interpret timestamps. The description is complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description adds valuable context: session_id must include the token suffix and never be stripped, and job_id can be discovered via tfruns. This improves parameter understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool checks the status of Terraform deployments, specifying it returns job status, job_id, and metadata. It distinguishes itself from siblings by referencing tflogs for streaming logs and tfruns for discovering IDs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use ('quickly check if a deployment is running, completed, or failed'), when not to use (use tflogs for logs), and prerequisites (session_id from convoopen). Also provides alternatives for discovering job IDs and streaming logs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses critical behavior: returns session_id with ?token= suffix, without which downstream tools 401; explains Riley will ask questions; details response content. Annotations only provide openWorldHint and destructiveHint, so description adds extensive context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections (WORKFLOW, CRITICAL, OPTIONAL, IMPORTANT, TIP). Slightly verbose in token explanation, but given the critical nature, it is justified. Front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema, description explains response contains Riley's message and metadata with session_id. Covers all parameters and workflow integration. Complete for its role as initial step.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% parameter description coverage, but description enriches each: for 'source' adds auto-detection and requiredness; for 'project_context' adds do's and don'ts with example; for 'github_username' explains attribution. Adds significant value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is 'Step 1 of 4 - Start infrastructure design conversation' and 'Open an InsideOut V2 session'. It distinguishes from sibling tools like convoreply and tfgenerate by placing it as the first step.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit keywords for when to use ('setup my cloud infra', etc.), warns not to answer Riley's questions on behalf of the user, and emphasizes the necessity of passing session_id verbatim to downstream tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint, openWorldHint) are confirmed and expanded upon: describes fetching temporary read-only credentials, working after failed deploys, response tiers, and required IAM roles. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with headings, bullet lists, and examples. Slightly verbose but all content is useful. Front-loads key info (prerequisite, purpose). Minor redundancy (e.g., 'INSPECTION:' header repeated).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 required parameters, no output schema, the description covers prerequisites, usage, response tiers, examples, IAM roles, and service list comprehensively. Sufficient for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds extensive value: explains session_id format and requirement, lists all services, provides action examples, filter examples, and clarifies detail/raw behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it inspects GCP infrastructure after a deployment attempt, with a specific verb ('inspect') and resource ('GCP infrastructure'). It distinguishes from sibling tools like awsinspect (AWS) and gcpinspect_batch (batch variant) by focusing on GCP and single-queries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states prerequisite (deployment attempt, checks convostatus), when to use (user asks about status/details), and provides examples. Does not name alternatives directly, but the context of 'inspect' vs other tools is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds rich behavioral context beyond annotations: budgets (max 32, timeouts, concurrency, response cap with truncation), partial failure handling, credential fetch behavior, and summarized responses. Annotations already indicate read-only and open-world, which description complements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-organized with headers, bullet points, and examples. Slightly verbose but all content adds value. Front-loaded with main purpose. A minor trim could make it more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers prerequisites, budgets, failure modes, response structure, examples, and comparison with siblings. Despite no output schema, description explains the response format. Highly complete for a batch tool with partial failure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% but description adds significant value: session_id must include ?token= suffix, subs array constraints and concurrency details, and examples illustrate usage. Goes well beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it runs up to 32 GCP inspect probes in one call, distinguishes from singular gcpinspect by specifying batch is for >3 resources, and notes singular is for discovery or full metadata.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to use when checking >3 resources, not for discovery, provides prerequisite (deploy attempt required) and alternative (singular gcpinspect for full metadata).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds significant behavioral context beyond annotations: single-flight guard, returns job_id/plan_id/project_id, credential handling, and no destructive changes. Annotations already indicate idempotent and non-destructive, consistent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections and front-loaded purpose, but somewhat lengthy. Could be slightly more concise without losing information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Comprehensive coverage of all aspects: parameters, single-flight, output (via job_id/plan_id), streaming, application flow, credential requirements. No output schema but description covers needed context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Even with 100% schema coverage, description adds valuable nuance: sandbox behavior, force_new guard usage, session_id format requirement ('sess_v2_...?token=...').
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that tfplan runs terraform plan to preview infrastructure changes without applying. It distinguishes from siblings like tfdeploy (apply) and tflogs (stream output).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use (preview before applying) and when-not (single-flight constraint, force_new only for wedged runs). Names alternatives like tfdeploy and tflogs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (openWorldHint: true, destructiveHint: false), the description adds crucial behavioral context: it warns against answering Riley's questions, specifies that it requires session_id, details retry logic, timeout limits, and explains key response signals. This goes well beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (WORKFLOW, CRITICAL, KEY SIGNALS, etc.) and bullet points. Every sentence adds value, and critical guidance is front-loaded. Despite length, it avoids redundancy and is easy to follow.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the multi-step workflow and absence of an output schema, the description is remarkably complete. It covers prerequisites (session_id from convoopen), workflow phases, alternative tools, response signals, and usage tips. No gaps remain for the agent to infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
While schema coverage is 100%, the description adds significant meaning: for 'text' it instructs to forward verbatim, for 'project_context' it specifies only new details, for 'session_id' it emphasizes exact format including '?token=', and for 'retry' and 'timeout' it clarifies usage with defaults and limits.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Step 2 of 4 - Continue infrastructure design conversation' and 'Send a user message to the active InsideOut session and receive the assistant reply.' It clearly identifies the verb (send), resource (user message to session), and context (workflow step), distinguishing it from siblings like convoopen and tfgenerate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use ('after convoopen', 'before tfgenerate') and when-not-to-use ('DO NOT call tfgenerate until this tool returns!'). It also mentions alternative tools (e.g., convostatus for checking progress) and gives critical workflow phases (conversation → tfgenerate → tfdeploy).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description discloses pagination behavior, response fields, and context window warning. Consistent with readOnlyHint and openWorldHint annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with sections for job states, pagination, response fields, and notes. Each sentence adds value, no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete coverage of two operational modes, pagination, all parameters, and response fields. No output schema, but response fields are described. Contextual warning about log size adds completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds significant value: explains default behavior for job_id, timeout range, last_event_id pagination cursor, and session_id format with token suffix warning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'MONITORING: Fetch Terraform deployment logs with pagination' and clearly states it fetches logs from running or completed jobs, distinguishing it from sibling tools like tfdeploy or tfruns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance on when to use REST vs SSE, pagination steps, use of tail to avoid large context, and prerequisite session_id from convoopen. Clear when-not conditions implied by the different job states.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![insideout-agent-skills MCP server](https://glama.ai/mcp/servers/luthersystems/insideout-agent-skills/badges/card.svg)](https://glama.ai/mcp/servers/luthersystems/insideout-agent-skills)

Score Badge

Copy to your README.md:

[![insideout-agent-skills MCP server](https://glama.ai/mcp/servers/luthersystems/insideout-agent-skills/badges/score.svg)](https://glama.ai/mcp/servers/luthersystems/insideout-agent-skills)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/luthersystems/insideout-agent-skills'

If you have feedback or need assistance with the MCP directory API, please join our Discord server