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?

With no annotations, the description carries the full burden and does an excellent job: it discloses that the brief 'spends one of the account's tracked platforms' and that re-briefing an already-spent platform is free. It also explains the project constraint (a project cannot be issued another brief until the current one has an outcome recorded). These are non-obvious behavioral traits an agent must know.

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 longer than average but every sentence carries meaningful information, from the core purpose to the cost model and the alternative tool. It front-loads the main value and then details the paid/optional part. Slightly dense but not wasteful; a 4 reflects efficient use of length.

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 read-oriented tool with 3 parameters and no output schema or annotations, the description covers everything an agent needs: what data is returned (including the optional brief fields), the cost/behavior, the project constraint, and when to use an alternative. 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 description coverage is 100% and the schema itself is richly descriptive (explains the paid nature of brief, the project constraint, and when to omit projectId). The description text adds minimal additional parameter meaning beyond what the schema already provides, so baseline 3 is appropriate.

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

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

The description explicitly states it returns a 'full record for one platform' and enumerates the content (eligibility, disqualifiers, submission instructions, requirements, gotchas, expected outcome). It also distinguishes itself from siblings by mentioning the brief (agentPrompt/agentGotchas) and referencing submission_playbook, so an agent can clearly tell it apart from search_platforms and submission_playbook without opening schemas.

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 when-to-use guidance: it says to ask for the brief 'once the maker has decided to fill this form, not while you are still choosing between platforms' and that submission_playbook returns the same brief with values pre-filled for stored projects. It also states that eligibility and disqualifiers come back even without the brief, making the decision context 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, the description carries the full burden, and it delivers: it discloses that the next brief is refused until this call is made, that planned frees the run without claiming an outcome, that attempted carries verification for later settling, and that re-sending forms to test is not the right approach. This goes well beyond the structured schema and gives the agent a clear model of side effects and workflow consequences.

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 but lengthy and somewhat conversational, with several clauses stacked into long sentences. The purpose is front-loaded, but the behavioral guidance could be tightened without losing meaning. It earns its place overall, but is not a model of conciseness.

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 tool with no output schema and no annotations, the description is remarkably complete. It covers when to call, what statuses mean, how to handle uncertain submissions, how to handle platform-side requirements, cost implications, and workflow blocking. An agent has enough context to invoke the tool correctly in the full range of intended situations.

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 86%, so the schema already documents most parameters. The description adds meaningful semantic nuance on top: it explains the exact meaning of attempted as distinct from submitted, requires note for planned, and clarifies when launchAt/submittedAt are relevant. It does not add anything about platformSlug, but the schema gap is minor and mostly inferable.

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 clear verb and resource: 'Log what happened to the dashboard: the listing URL, when it was sent, when it goes live.' It clearly identifies this as a recording/logging tool for submissions. However, it does not explicitly contrast itself with sibling tools like plan_submissions or submission_playbook, though the purpose is inferable from context.

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-use guidance: call it as soon as a submission lands, before asking for the next brief, including queued-review and uncertain-landing cases. It also specifies the planned status usage for platforms waiting on the maker and explains that record status costs nothing on any plan. This is strong, actionable routing information.

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 disclosure burden and does so thoroughly. It reveals the one-brief-per-project refusal behavior, the free-plan metering with upgrade redirection, the sign-in decision path, and the presence of gotchas/agentGotchas, all of which are non-obvious behavioral traits affecting invocation.

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 text is a single dense paragraph packed with caveats and embedded clauses, making it harder to scan. Every sentence does convey a distinct operational fact and the purpose is front-loaded, but restructuring into bullets or shorter sentences would improve clarity significantly.

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?

Despite having no output schema and no annotations, the description thoroughly covers what the tool returns, when it refuses, how metering works, and how sign-in is handled. The only minor gap is enumerating exact platform slugs, but the description points to account/platform context and related sibling tools, which is sufficient for an agent to proceed.

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?

Two of three parameters already have detailed schema descriptions, so the description adds marginal value for signInAs and projectId. The missing piece is platformSlug: the schema gives only a type, and the description never explains what platform slugs are valid or where to obtain them, leaving the one required parameter under-specified.

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 identifies the tool as the complete submission brief for a stored project on one platform and distinguishes it from record_submission, which is the follow-up call. However, it lacks an explicit verb like 'fetch' or 'return,' presenting the tool as a noun phrase ('Everything needed to submit...') rather than stating the core action directly.

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 strong operational context: read the preflight before opening a tab, fetch one brief at a time, never fetch ahead or in parallel, and wait for record_submission before requesting the next platform. It does not, however, compare this tool against sibling planning tools like plan_submissions, so some alternative routing is left implicit.

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.