directory

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the behavioral disclosure burden, and it does so well: it explains that facts drive qualification while pack is what gets pasted into forms, that assets come as URL/file pairs, and that logoFile is a local path that cannot be displayed. It stops short of covering auth, idempotency, or error behavior, so it is not a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The paragraph is dense but focused: the opening sentence states purpose, and the following sentences each add workflow or image-handling guidance without repeating schema content. It could be more scannable with structuring, but no sentence feels like padding.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema or annotations exist, yet the description provides enough operational context for a complex nested creation tool: it clarifies pack vs facts, image/file behavior, the update_project handoff, and the expected filled-in result. Missing explicit return value, error, and duplicate-handling details prevent a perfect score.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description adds meaning beyond the schema by explaining the conceptual split between facts and pack and detailing the URL/file duality for logo and media assets. It does not enumerate top-level url/name/pitch, but schema already describes pitch and many nested fields, so the partial compensation is still strong.

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 opens with a concrete action, 'Store a product on the account', and later contrasts itself with update_project by saying to 'come back with update_project'. This makes the tool's purpose distinct from siblings and not simply a restatement of its name.

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 gives explicit when-to-use guidance: first use visible evidence from README, metadata, and site copy, fill as much as possible, ask only about genuinely missing facts, then follow up with update_project. It also prioritizes image questions early, which is concrete operational advice.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist, so the description carries the behavioral disclosure burden. It clearly discloses that the brief option spends a tracked platform, that already-spent platforms are free to re-brief, and what each response tier contains. It omits error/edge-case behavior, but the core operational and cost-related traits are well covered.

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?

Every sentence earns its place: the free contents are front-loaded, the paid option is explained with concrete examples, and the tool-routing caveat is placed at the end. It is dense but not bloated, and all guidance is decision-relevant.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description fully explains what the tool returns in both modes and covers the key operational nuance of spending a tracked platform. It also gives enough context for an agent to decide between plain lookup, brief inclusion, and submission_playbook. Nothing essential for selecting and invoking the tool 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?

The schema already describes both parameters thoroughly, so the baseline is 3. The description adds meaningful context beyond the schema by explaining the cost implication of brief=true, when to omit it, and that submission_playbook is the relevant alternative for stored projects. This raises it above the baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific operation: retrieving the full record for one platform, and enumerates the record's content (eligibility, disqualifiers, instructions, gotchas, expected outcome). It also distinguishes itself from the sibling submission_playbook by explaining that the sibling returns the same brief pre-filled with a stored project's values.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit timing guidance: the free portion should be used while deciding whether to submit, while the paid brief should only be requested after the maker has decided to fill the form. It also names the alternative tool, submission_playbook, for stored projects, making the choice between siblings clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden. It explains the output structure (facts, pack, missing items) and the role of the returned ID for other tools. It implies read-only behavior by describing a listing operation, though it does not explicitly state side effects or permissions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loading the primary function and then delivering a crisp use case. Every phrase contributes to understanding the tool's purpose and usage, with no redundant 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?

Given no output schema, the description explains the key return elements: projects with facts, pack, missing items, and an ID usable by other tools. It places the tool within the broader toolset. It could be slightly more explicit about the output format (e.g., array of projects) but that is easily inferred.

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 has zero parameters, so the description need not explain input schema. The schema coverage is trivially 100% with an empty object. The description focuses on output semantics, which is appropriate for a parameterless list operation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states that the tool lists all projects on the account, each with its facts (eligibility answers), pack (submission form fields), and missing pack items. It also distinguishes itself as the means to resolve ambiguous references to 'my project', setting it apart from sibling tools that require an ID.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit when-to-use guidance: 'Call it whenever the maker says "my product" or "my project" without naming one' and explains that every other account tool takes the ID it returns. This clearly differentiates when to use this tool versus others.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

There are no annotations, so the description carries the transparency burden. It strongly implies a read-only status lookup through 'Where every submission for a project stands' and 'what came back, and what is still waiting', and says the tool answers from stored data rather than memory. It does not explicitly state 'read-only' or discuss data freshness/authorization, but the behavior is clearly non-mutating.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, every one earning its place: functionality, user-query mapping/guidance, and a prerequisite. No repetition of the schema or tool name, and the tone is engaging without bloat.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with one optional parameter and no output schema, the description fully covers what data the user wants, which queries map to it, and what to do before calling it. It is complete for an agent to select and invoke 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 for the single parameter is 100% (projectId), so the baseline is 3. The description adds value by telling the agent to call list_projects first when no project is named, which indirectly clarifies when projectId is needed or can be omitted. It also reinforces the project context through example queries.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly defines the tool as a status dashboard for project submissions, listing exactly what information it provides (what went out, when, what came back, what is waiting). It also distinguishes itself from sibling tools by explicitly positioning it as the answer to 'check my submissions' and similar queries, rather than record_submission or plan_submissions.

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 gives explicit user language triggers ('check my submissions', 'what did I submit') and a concrete precondition: 'Start with list_projects if they have not named a project.' This tells the agent exactly when to call this tool and what to do first.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full behavioral burden and delivers: already-submitted items are dropped and echoed back in `alreadySubmitted`, the plan renders as a dashboard checklist that ticks itself off, already-tracked items are reordered rather than reset, and planning costs nothing. It discloses return behavior, side effects, and idempotency — far more than the schema or annotations could convey.

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?

Roughly 220 words, but every sentence contributes a distinct piece — purpose, return behavior, parameter handling, dashboard side effect, reorder-not-reset semantics, workflow scheduling, and cost. The purpose is front-loaded and there is no filler; the lenth is earned by the absence of annotations and an output schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (4 params, cross-tool workflow, no annotations, no output schema), the description is remarkably complete: it covers when to call, precenditions, what gets excluded, the key return field (`alreadySubmitted`), idempotent reordering, and cost. The only minor gap is the full return shape, and the most consequential part of it is explicitly named.

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 real value: items must be passed in work order with a short reason each, the summary is read by the maker, and the checklist must be 'written from what the platforms in this plan actually demand and what the project is missing, not from a generic template,' with decisions surviving re-plans. This meaningsfuly extends the schema's bare field names.

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 opening sentence, 'Write the run order for a project: which platforms, in what sequence, and why each one is where it is,' gives a specific verb, resource, and scope in one breath. It also distinguishes itself from siblings by naming its workflow position ('Call it after qualify_project') and implying a contrast with record_submission (planning vs. recording).

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?

'Call it after qualify_project, using the `recommended` list it hands back' is explicit when-and-with-what guidance tied to a named sibling. The conditional 'if that response carried `questions`, put them to the maker before you plan: the order depends on the answers, and a plan written on an assumption is one they have to undo by hand' is an explicit when-not with a concrete consequence, and the already-submitted exclusion tells the agent what to leave out.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full behavioral disclosure. It reveals assumptions (goal/budget defaults), that unanswered fields become gaps rather than rejections, that it does not require an account, and that it suggests storing answers via a separate tool. This is transparent about its non‑mutating nature and the kind of output it produces, covering important behavioral expectations.

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 fairly long but each sentence adds meaningful content: purpose, output, ordering logic, assumptions, workflow, and account requirement. It is front‑loaded with the core purpose and logically structured, though a bit verbose for a tool description. It earns its length given the tool's complexity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description explains the output categories and the recommended order, and the next steps (ask questions, call again, store). It does not detail the exact return structure or enumerate the criteria for each qualification tier, but given that there is no output schema and the tool's complex behavior, it provides enough for an agent to invoke it and process the result sensibly.

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 19% (goal, budget, categories, launchAt), and the main description does not define most of the 21 parameters. It does add global semantics: every field is optional and missing fields become gaps to fill. This helps, but it does not explain individual boolean/attribute fields (e.g., docs, demoVideo, coverImage) beyond being product attributes. The description compensates at a high level but not per‑parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description is explicit: it states the tool qualifies a product against platforms, distinguishing three outcomes (qualifies now, qualifies after filling gaps, structurally out of reach). It also names the `recommended` output and how it is derived, clearly differentiating from siblings like search_platforms and plan_submissions by focusing on qualification and ordering.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear context: it is used inline without an account, takes product details, and every field is optional. It explains the workflow of asking questions, calling again, and storing answers via update_project. However, it does not explicitly name alternative tools or state when not to use it, though the overall flow implies its use case.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden. It adds useful behavioral context: 'This costs nothing on any plan and no status costs more than another' and encourages recording 'what actually happened.' However, it does not disclose whether calls are idempotent, whether records can be overwritten, what happens on error, or what the tool returns, which are material for a logging 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?

The description is front-loaded with the core purpose and is about three sentences. It avoids much of the fluff, though the phrase 'the brief was what spent the tracked platform' is cryptic and slightly undermines conciseness. Overall, each sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the main call context, including queued submissions and uncertain landings, and gives cost-related reassurance. It does not explain return values or persistence behavior, but there is no output schema and the tool is a simple logging action. The essential information for choosing and calling it correctly is present.

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 71%, which establishes a baseline of 3. The description adds some mapping context by referencing 'the listing URL, when it was sent, when it goes live,' which aligns with `listingUrl`, `submittedAt`, and `launchAt`. It does not clarify `note` or `platformSlug`, but the schema already covers the other parameters in reasonable detail.

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 opens with a specific verb and resource: 'Log what happened to the dashboard' and names the key pieces of data (listing URL, when it was sent, when it goes live). It clearly stands apart from siblings like list_submissions and plan_submissions, which are about retrieval and planning rather than recording.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit when-to-call guidance: 'Call it as soon as a submission lands, including when it is only queued for review, and including when you are not sure it landed.' It also clarifies the intended use of the `attempted` status. It does not explicitly name alternative tools or when to avoid using this tool, but the invocation conditions are clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the disclosure burden and does disclose useful behavioral traits: it searches the entire directory, respects a project tracker when a token is supplied, and returns summaries rather than full records. It could add more about auth/rate limits, but for a read-only search tool the behavior is adequately transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Every sentence pulls weight: the first lists what the tool searches and how to filter, the second gives the concrete user phrase and the authoritative source over model memory, the third explains the return type and the next tool. It is dense but well-structured and front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For 12 optional parameters and no output commentary, the description tells the agent what to use, what to filter by, what the source of truth is, and what to call next for full details. It is complete enough though it stops short of describing return field shape or pagination behavior.

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 high at 92%, so the input schea carries most of the parameter meaning. The description adds context about filtering concepts and the token-gated excludeTracked behavior, but mostly names parameters rather than revealing details beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a clear verb and resource: it searches the SubmitMap directory of startup launch platforms. It also distinguishes itself from the get_platform sibling by noting it returns summaries rather than full records, and frames itself as the tool behind a concrete user request.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly describes when an agent should use it (whenever the user asks for a directory to submit to, and when asked about what is in the directory rather than memory). It also directs the agent to call get_platform for full record details including submission steps, which is a clear alternative.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden, and it is unusually rich: it reveals the tool's internal components, the first-submission sign-in question, the signInAs hand-off, form-specific traps, and the upgrade fallback behavior. It stops short of stating whether calling the tool itself has side effects or what the exact return structure is, but the 'call to make afterwards' phrasing strongly implies it is informational rather than directly submitting.

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 information-dense and front-loads its purpose, but the first sentence is a long run-on with nested parentheticals that makes parsing harder than necessary. The content mostly earns its place, but the structure would benefit from a bulleted list or clearer separation of the playbook components, metering caveat, and usage instruction.

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 is responsible for explaining return contents, and it lists many of them clearly. Still, it leaves some actionable details vague: 'the call to make afterwards' does not identify the tool, and required platformSlug semantics are absent. For a moderately complex tool with no annotations and no output schema, these are real completeness gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already provides strong descriptions for signInAs and projectId, covering 67% of parameters. The description adds useful context for signInAs by explaining the maker-question and safe fallback. However, the required platformSlug parameter is left completely undescribed in both the schema and the description, which is a meaningful gap.

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 and scope: a playbook for submitting a stored project to one platform in the maker's browser. It also enumerates the contents (preflight, sign-in plan, mapped pack values, steps, gotchas, agentGotchas, and the call to make afterward). It lacks an explicit verb like 'returns' or 'generates,' and it does not directly name sibling alternatives, so it stops short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives clear usage context: read the preflight before opening a tab, and the tool is the one the free plan meters. It also defines an eligibility boundary: beyond the covered submissions it points at the upgrade rather than answering. However, it does not explicitly compare against siblings like plan_submissions or record_submission, so alternatives are implied rather than stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It explicitly discloses the merge semantics ('Facts and pack are merged into what is there') and the incremental nature, which is critical for an agent to know it won't overwrite unmentioned fields. It does not cover error cases or idempotency, but the core behavior is transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence that front-loads the purpose and key behavior. It avoids verbosity and is easily scanned. However, given the tool's complexity, it is almost too terse—it omits context that might be expected at this level, though it remains structurally efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has complex nested objects and many optional fields, yet the description ignores how to select the project (projectId), what happens if no projectId is given, and how pack relates to facts. With zero annotations and low schema coverage, an agent lacks critical context to call this tool correctly without additional probing.

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 only 17%, yet the top-level description adds no parameter-level explanation. It does not clarify that 'projectId' is optional or how 'pack' and 'facts' relate. The schema itself covers some nested fields, but the description fails to compensate for the low coverage, leaving many parameters underspecified.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states a specific verb ('Fill in or correct') and resource ('a stored project'), which unambiguously distinguishes it from create_project. It also communicates the incremental merge behavior, leaving no doubt that this tool patches existing data rather than creating new records.

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 hints at a usage pattern ('as the maker answers') but gives no explicit when-to-use guidance, no alternatives, and no exclusions. It does not mention that create_project should be used for new projects or that qualify_project fills gaps, so an agent must infer when to choose this tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden of disclosure. It reveals what the tool returns (email, plan, existing holdings) and what it does not (plan limits), effectively implying a read-only identity operation. It doesn't explicitly state there are no side effects, but that's implied by the context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description packs useful information but is somewhat wordy, with a cryptic final sentence ('plan the whole run, and a limit says so at the write it stops') that may puzzle an AI agent. The core purpose is front-loaded, but the extra guidance could be tightened for clarity.

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 no-parameter identity tool, the description sufficiently covers what it does, what it returns, and when to use it. It even clarifies what it doesn't return (plan limits). It lacks exact output formatting details, but that's minor given the simplicity.

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 has zero parameters, so there is no schema to elaborate. The description adds meaningful output context (email, plan, holdings) that goes beyond the empty input schema, though parameter-specific semantics are not applicable.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states what the tool does: it identifies which SubmitMap account a token belongs to, including the associated email, plan, and held items. This is a specific identity-check function that is distinct from sibling tools like list_projects or create_project, which focus on other actions.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidance on when to call it: 'Call it first if you are unsure whether the maker is connected' and emphasizes it's the only way to distinguish accounts. It also advises against using it for plan limits ('It does not hand you the plan's limits'), but doesn't name alternative tools for that purpose.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.