Check a name on 29 platforms and the domains; build and follow apps you own on SPOE.
Scored across 10 tools
Each tool has a clearly distinct role: creation (create_app vs new_project), file access (list/read/write), status (app vs change), and checks (project vs handle). The two creation tools could look similar at first, but their descriptions clearly separate AI-built apps from blank starter projects.
All names use consistent snake_case and are readable. Most are verb_noun, but app_status/change_status are noun_status and new_project uses a different creation verb than create_app, so the pattern is not perfectly uniform.
Ten tools is well-scoped for an app-building platform: creation, listing, file operations, status tracking, and validation checks. Each tool appears to earn its place without obvious redundancy.
The surface covers the main lifecycle: create blank or AI-built projects, inspect files, submit changes, check statuses, and run ship/brand checks. Some operations such as deleting/archiving a project, explicit publishing/exporting, or app metadata updates are not exposed as tools, though many may be handled in the studio.
Show where an app on this account stands: its latest build (queued, generating, reviewing, waiting for the owner, applied, failed), the review's verdict, and its live address when published.
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | Yes | The project id from create_app or list_apps. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already carry the safety profile (readOnlyHint=true, openWorldHint=false), so the description's added value is the lifecycle enumeration (queued, generating, reviewing, waiting for the owner, applied, failed) and the fact that a verdict and published address may accompany it. That tells an agent what states to expect and interpret, though it says nothing about permissions, latency, or staleness of the status.
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?
A single sentence with the main purpose front-loaded and the build states inline rather than as a separate list. Dense but with no filler; every clause maps to something the tool actually reports.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description must describe the return payload, and it does: current build phase, review verdict, and live URL when published. For a one-parameter read-only status tool, nothing an agent needs to call it correctly is missing.
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%: project_id is documented in the schema itself, including where to obtain it (create_app or list_apps). The description adds no parameter-level detail, which is the expected baseline when the schema does the heavy lifting.
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?
A specific verb ("Show") plus a clearly bounded resource: the standing of one app on the account, decomposed into latest build state, review verdict, and live address. This is plainly distinct from create_app, list_apps, and check_handle, and the enumerated build phases make the scope of "status" unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied rather than stated: an agent can infer this is the tool to poll after create_app or to inspect a single app from list_apps. However, there is no explicit when-to-use statement, no mention of the siblings by name, and no note on whether it should be called repeatedly to track build progress.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Where a change sent with write_files stands: being reviewed, applied, or waiting for the owner, with every finding (severity, file, line, what is wrong and how to fix it). Fix the findings and send the files again with write_files.
| Name | Required | Description | Default |
|---|---|---|---|
| change_id | Yes | The change id write_files returned. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered; the description goes further by disclosing what the response contains — status states and structured findings with severity, file, line, problem, and remediation. It stops short of describing polling behavior or how long a review takes, which would be the remaining useful detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the status meaning and then the actionable next step. Every clause carries information — states, finding fields, and the remediation loop — with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and only one parameter, the description adequately covers return content and the intended workflow, which is what an agent needs to call and act on it. It could be slightly stronger by noting whether findings can be empty or whether repeated polling is expected, but nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the sole parameter's description ('The change id write_files returned') already explains provenance. The description reinforces the link to write_files but adds no syntax, format, or edge-case guidance beyond what the schema provides, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific resource — the status of a change submitted via write_files — and enumerates its possible states (reviewing, applied, waiting for owner) plus the findings payload. This clearly distinguishes it from siblings like app_status or check_project, though the verb is phrased indirectly ('Where ... stands') rather than as an explicit action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It establishes the preconditions (use after sending files with write_files) and the follow-up action ('Fix the findings and send the files again with write_files'), which effectively describes the review loop. It does not explicitly state when to avoid calling it or how the state relates to alternative tools, but the workflow context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check whether a brand name or username is free on X, YouTube, LinkedIn, GitHub, Shopify, Bluesky, Snapchat and more (29 platforms), and on the main domain endings (.com, .ai, .io, .com.au and others). Each platform is only trusted while it still calls a certainly-taken name taken; platforms that refuse checks (Instagram, TikTok, Facebook, Reddit) come back as "check yourself" with a link. Free, no API key needed.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | The brand name or handle, like "rosiebakes" or "@rosie_bakes". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnlyHint and openWorldHint; the description adds genuinely useful behavioral context beyond that — the trust model ('only trusted while it still calls a certainly-taken name taken'), and the degraded-result behavior for platforms that refuse checks (Instagram, TikTok, Facebook, Reddit return 'check yourself' with a link). It omits latency, rate limits, and partial-failure handling, so it is strong but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with what is checked and how many platforms, then the reliability caveat, then the cost model. Every sentence carries distinct information with no filler.
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 one well-documented parameter and no output schema, the description does the heavy lifting on results by explaining the 'check yourself' fallback shape. It could say more about what a successful result contains (per-platform statuses) and about partial failures, but it is sufficient for correct invocation.
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 supplies the format example ('rosiebakes' or '@rosie_bakes'), so the baseline is 3. The description's 'brand name or username' phrasing adds no syntax or normalization detail beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (check) and resource (brand name/username availability) with concrete scope: 29 named platforms plus domain endings. An agent can immediately tell this is a cross-platform availability lookup, distinct from the app-management siblings (app_status, create_app, list_apps).
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?
Gives clear operating context — free, no API key needed, and the coverage list — which helps an agent decide this is the right call for name availability. It does not, however, state any explicit when-not-to-use condition or point to an alternative tool, so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
SPOE's ship check on the project as it stands, free and with no AI: keys written in the code, SQL or shell commands built from text, raw HTML, cookies accepted from any site, routes that change data without sign-in, and what search engines will miss. The same check every export ships as check.mjs. A critical finding stops a publish until the owner confirms it, so fix those with write_files first.
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint=true and openWorldHint=false, and the description adds meaningful behavior beyond that: it is free and non-AI, lists what it checks, notes that it is the same check exported as check.mjs, and discloses the publish-gating behavior for critical findings. This adds useful operational context without contradicting the read-only annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two dense sentences with the core operation front-loaded followed by the critical-finding and write_files guidance. Every clause contributes something useful: what is checked, the export equivalence, and the publish gate.
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 one-parameter read-only check with annotations covering safety and no output schema, the description is largely complete: it explains scope, behavioral impact, and remediation path. It stops short of describing the result format or how to obtain project_id, but the annotation coverage reduces the burden on the description.
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?
There is one required parameter, project_id, but schema description coverage is 0% and the description does not specify its format, where to obtain it, or how it is interpreted. The phrase 'on the project as it stands' only weakly implies that project_id identifies the target, leaving the parameter largely undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: a ship check on the project as it stands. It enumerates the exact classes of issues checked (hardcoded keys, generated SQL/shell, raw HTML, permissive cookies, unauthenticated data-changing routes, SEO misses), which makes the tool clearly distinct from siblings like app_status or check_handle. Naming write_files as the follow-up for critical findings further clarifies its role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear usage context: the check is run before publish/export, critical findings stop a publish until owner confirmation, and those should be fixed with write_files first. It does not explicitly state when not to use it or compare directly against sibling tools such as check_handle, so it falls short of a full when/when-not/alternatives treatment.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start building a new app, website or game on SPOE from a description. kind "website" makes a plain HTML site (fast, can be published at name.spoe.dev); kind "app" makes a full-stack Next.js, Fastify and Postgres app; kind "game" makes a browser game (Phaser for 2D, Three.js for 3D) that plays on a computer and a phone, can be published at name.spoe.dev, and borrows the mechanics of any games it is asked to be like, never their names, characters or art. A second AI from another model family reviews the change. Costs credits from the account: estimated first, charged when the build finishes, never if it fails. Returns the studio link to watch it and the project id for app_status.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | website (plain HTML), app (full stack) or game (a browser game). Default website. | |
| name | Yes | A short name for the project. | |
| description | Yes | What to build, in plain words: who it is for, the pages, what it should do. For a game: the kind of game, games it should be like, the controls and the goal. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations: discloses the credit cost model (estimated first, charged on completion, never on failure), the second-model-family review step, the IP constraint that a game borrows mechanics but never names/characters/art, and publishing to name.spoe.dev. Nothing in the annotation set (readOnly/idempotent/destructive) covers any of this.
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?
A single dense paragraph, front-loaded with the action before the kind breakdown and cost notes. Every clause carries information, though the long compound sentences about game IP and cost sequencing slow scanning slightly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, and the description compensates by stating what is returned (studio link plus project id for app_status). Costs, review behavior and kind semantics are all covered, so an agent has everything needed to invoke it 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 coverage is 100%, so the baseline is 3, but the description adds meaning the schema does not: it explains what 'kind' produces in each case (engines, publishability) and specifies what the free-text 'description' should contain for games (kind, comparable games, controls, goal). That is above-baseline enrichment of the same parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Start building a new app, website or game on SPOE') and decomposes the three output kinds with distinct technical meaning. It also names the downstream sibling ('the project id for app_status'), so an agent can place it in the workflow without opening either schema.
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?
Gives clear selection criteria for the 'kind' enum (website = plain HTML and publishable, app = full-stack, game = browser game with specific engines), which is real when-to-use guidance. It stops short of stating exclusions or prerequisites relative to siblings like list_apps or check_handle, so it does not reach a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the apps, websites and games on the SPOE account this API key belongs to, newest first, with their studio links.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered; the description adds real behavioral detail beyond that — ordering ('newest first') and that results include studio links, and that 'apps' spans apps, websites and games. It stops short of mentioning pagination or result limits, which is the one remaining gap for a listing tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with zero filler; the resource scope is front-loaded and the ordering/detail qualifiers are appended compactly. Nothing could be removed without losing information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description must carry return-value information, and it does so partially (contents, ordering, studio links). It leaves pagination or result-size behavior unspecified, which is a minor but real gap for an enumeration tool on a read-only, no-parameter endpoint.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the baseline of 4 applies. There is nothing for the description to clarify about inputs, and it correctly does not invent any.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('List') plus the exact resource scope: apps, websites and games belonging to the SPOE account tied to this API key. That scope makes it unmistakably distinct from create_app, app_status, and check_handle without needing to name 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?
Usage is implied rather than stated: an agent can infer this is the tool for enumerating the account's apps, but there is no explicit when-to-use guidance, no exclusion of related siblings, and no note on what to use when the result set is large.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Every file in a project on this account, with its size. Files in site/vendor/ are game engines and generated files are made by SPOE: read them, never write them.
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | Yes | The project id from new_project, create_app or list_apps. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint=true, openWorldHint=false), and the description adds genuinely new context: the listing spans the whole project on this account and includes sizes. The warning that site/vendor/ files are engines and SPOE-generated is real operational guidance an agent would not get from 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences, front-loaded with scope and return content, followed by the constraint. The 'SPOE' reference is unexplained but costs little space.
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 tool with no output schema, the description covers scope, a returned field (size), and a write-avoidance constraint. Pagination or ordering behavior is not mentioned, which is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the project_id description already points to new_project, create_app, and list_apps as sources. The description says 'on this account' but adds no format or sourcing detail beyond what the schema provides, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Every file in a project') and adds a return detail ('with its size'), so the agent knows it's an enumeration tool rather than the single-file read_file sibling. It never names read_file or list_apps explicitly, so differentiation is inferred rather than stated.
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 'read them, never write them' line gives indirect usage guidance for vendor/generated paths, but there is no explicit when-to-use or when-not-to-use versus read_file, write_files, or list_apps. The agent must infer that this is the discovery step before read_file.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Make a new SPOE project from SPOE's starter, with nothing built yet and nothing charged, for you to write with write_files. kind "app": Next.js 15 (web/, app router, React 19) with a Fastify API (api/src) on Postgres (migrations in api/migrations, numbered .sql files), owner pages behind ADMIN_PASSWORD, and a rate limiter in api/src/limits.js. kind "website": plain HTML, CSS and JavaScript in site/. kind "game": Phaser 3 or Three.js in site/, with the engines in site/vendor/ (never edit those). Returns the project id, its studio link (live preview, publish, export) and the starter's files.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | app (full stack), website (plain HTML) or game. Default app. | |
| name | Yes | A short name for the project. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well past the annotations by disclosing cost behavior ('nothing charged'), the empty initial state, the concrete stack and file layout for each kind, the ADMIN_PASSWORD-protected owner pages, and an explicit constraint not to edit site/vendor/. It also states what is returned (project id, studio link, starter files), which is significant since no output schema exists.
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?
Front-loads the core action and cost/state guarantee in the first clause, then enumerates the three kinds in a parallel, scannable structure. The per-kind stack detail is long but earns its place by driving the enum decision; only minor trimming would be possible.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description supplies the return contract (project id, studio link for preview/publish/export, starter files), covers both parameters, and flags the vendor-directory constraint. Nothing needed to invoke it correctly or interpret the result is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description materially expands the 'kind' enum by describing what each starter actually contains (Next.js 15 + Fastify + Postgres vs plain HTML vs Phaser/Three.js in site/vendor). That lets the agent choose a kind without guessing at the schema's one-line enum labels.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Make a new SPOE project from SPOE's starter') plus the resulting state ('nothing built yet'), and names the follow-up tool (write_files) so the agent knows what this tool is for. It is clearly distinct from the create_app sibling by being an empty starter scaffold rather than an app deployment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly positions the tool as the starting point for authoring ('for you to write with write_files'), which tells the agent the workflow context. It does not, however, say when to prefer this over create_app or list_apps, so the sibling differentiation is implicit rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One file of a project on this account, as it stands now (with every applied change and the owner's own edits).
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | The file's path, like web/app/page.tsx or site/index.html. | |
| project_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description does add real value by disclosing freshness semantics ('as it stands now, with every applied change and the owner's own edits'), which tells the agent it sees live state. However, it says nothing about file-not-found behavior, size or binary handling, or what a successful call yields.
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?
It is a single compact sentence with no filler, but it is a noun phrase rather than front-loading the action, and the freshness caveat is buried in a parenthetical. Efficient but not well structured for tool selection.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description must say what comes back, and it never states that the file's contents are returned. Combined with the undocumented project_id and no error or scope notes, an agent cannot confidently call this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 50%: 'path' is documented in the schema but 'project_id' is completely undocumented in both places. The description does not mention either parameter, so it fails to compensate for the coverage gap on project_id.
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 the resource ('One file of a project on this account') and implies retrieval, but never uses a verb like 'read' or 'returns the contents'. It is distinguishable from list_files by the singular 'one file', but an agent must infer that the content is returned rather than metadata.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this rather than list_files (to discover paths first) or write_files (for mutation). Neither sibling nor any precondition is mentioned, leaving routing entirely to inference from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send a change: whole files to write (path and full content) and files to delete. SPOE checks it (for an app: its migrations on a fresh Postgres and its API routes) and a second AI from another model family reviews it. On a project that applies changes on its own (the default) a change the review passes goes in as a version the owner can undo; one with a high or critical finding, or over a file the owner edited since, waits for the owner in the studio. Costs only the review's credits (estimated now, charged when it finishes, never if it fails). Then call change_status: fix what the findings say and send the files again.
| Name | Required | Description | Default |
|---|---|---|---|
| files | Yes | Up to 200 files, 3 MB of text in all. Each is { path, content } to write the whole file, or { path, delete: true }. | |
| summary | Yes | What this change does, in a sentence or two. The reviewer reads it beside the files. | |
| project_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds substantial context beyond the annotations: automated check plus a second-model review, auto-apply default with an undoable version, and a queue path for high/critical findings or files the owner edited. It also discloses the credit model (estimated up front, charged on completion, free on failure). The 'delete' capability alongside destructiveHint=false is defensible because changes are framed as undoable versions, but the tension is left for the agent to resolve rather than stated outright.
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?
Front-loaded with the action and the payload shape, then the review/apply behavior, then the cost note and next step – a sensible order with little waste. It is dense with parentheticals and uses the undefined acronym 'SPOE', which costs some readability.
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 mutation tool with no output schema, it covers the review pipeline, auto-apply vs. queued outcomes, cost, and the next step. The notable gap is the immediate return value – it tells the agent to call change_status but not what handle or status write_files hands back.
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?
With 67% schema coverage the schema already documents the file list shape, the whole-file content rule, and the review-facing summary. The description reinforces the whole-file semantics but says nothing about project_id and does not explain what identifying value (if any) comes back to feed change_status. Marginal value over 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?
States a specific verb and resource up front: send a change consisting of whole files to write (path + full content) and files to delete. It is clearly distinguishable from read_file/list_files and explicitly hands the follow-up to change_status, so an agent can place it in the toolset without opening a schema.
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?
Gives a concrete workflow: send the change, then call change_status, fix findings, and send files again. It also explains the two outcomes (auto-applied as an undoable version vs. queued for the owner), which tells the agent when a call is enough and when a re-send is needed. It stops short of explicit exclusions against sibling tools.
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.
change_statuscheck_projectlist_filesnew_projectread_filewrite_filescreate_app3 fields changedInput schema / properties / description / descriptionPrevious value: -"What to build, in plain words: who it is for, the pages, what it should do."New value: +"What to build, in plain words: who it is for, the pages, what it should do. For a game: the kind of game, games it should be like, the controls and the goal."Input schema / properties / kind / descriptionPrevious value: -"website (plain HTML) or app (full stack). Default website."New value: +"website (plain HTML), app (full stack) or game (a browser game). Default website."Input schema / properties / kind / enumPrevious value: -[
- "website",
- "app"
-]New value: +[
+ "website",
+ "app",
+ "game"
+]app_statuscheck_handlecreate_applist_appsCheck name availability on 70+ platforms: domains, social networks, marketplaces.
Check brand name availability on Instagram, TikTok, X, YouTube, GitHub and more in one call
Watch domains and forecast when they drop; check a name's domain, handles, and trademark.
Check if a brand name is free across domains, GitHub, npm and PyPI, and suggest available names.
Add one secure layer between your agents and this server.
