STEMPA seals one brief every AI reads the same way, with a signed receipt.
Scored across 18 tools
Most tools map to clearly distinct lifecycle steps: start, map, gaps, answer, dependency, freeze, skip, confirmations, and meta-help. The main overlap is among brief-reading/listing tools (grill_get, grill_brief, grill_list, stempa_briefs), but their descriptions distinguish in-progress/frozen/sealed scopes and verification by fingerprint.
All names are snake_case and use recognizable prefixes (grill_, confirmation_, stempa_), which helps grouping. However the pattern mixes verb-first actions (grill_start, request_feature) with noun-first or noun-only names (stempa_profile, stempa_receipt, grill_brief, confirmation_status), so it is readable but not a predictable verb_noun convention.
At 18 tools the server sits in the heavy/borderline range for a single MCP surface. Most tools correspond to real lifecycle operations, but the set is large enough that some users may need the namespace-like prefixes to navigate it.
The core brief lifecycle is well covered: create/start, fill sections, surface gaps, record answers, settle dependencies, freeze, skip, read, list, and retrieve sealed receipts. Minor gaps remain, such as no archive/delete operation or explicit dependency-inspection tool, and sealing is intentionally performed outside the server.
DRAFT ONLY - sends nothing, emails nobody, records nothing. Prepares a request asking a counterparty to
CONFIRM a change: content_hash is a version that amends a sealed brief (sealed, or waiting for the person's
seal); change_rows are map rows (dimension keys) that changed in it and are the change to confirm;
shared_rows are unchanged rows shown for context; title is the brief's name as the counterparty will
see it (default: the brief's own title). A ticked row is shown WHOLE, so never tick a row that mixes the
person's private facts with the counterparty's; a private row (private costs) can never be ticked. A
confirmation is a record of agreed scope, not a signed contract. The person reads, word for word, what the
counterparty will see and presses Send in their own STEMPA account; only that press sends anything.
| Name | Required | Description | Default |
|---|---|---|---|
| title | No | ||
| change_rows | Yes | ||
| shared_rows | No | ||
| content_hash | Yes | ||
| counterparty_email | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description discloses critical behavior: rows are shown whole, private rows must never be ticked, the confirmation is not a contract, and only the person's own Send action transmits anything. This gives the agent the operational and safety context needed to avoid misuse.
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 most important constraint ('DRAFT ONLY') and every sentence adds a meaningful behavioral or parameter detail. Despite its density, it stays focused and 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?
It covers the draft-only nature, the human send step, private-row restrictions, and key parameter meanings, while the output schema handles return format details. The main remaining gap is the lack of an explicit explanation of counterparty_email and what exactly the prepared draft returns or stores.
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 0% schema description coverage, the description carries the burden and explains content_hash, change_rows, shared_rows, and title in useful operational terms. It does not explicitly define counterparty_email, though the surrounding text makes the counterparty role clear.
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 object: it prepares a request asking a counterparty to confirm a change. The opening 'DRAFT ONLY' sentence immediately distinguishes this from any tool that sends or records the 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 clearly establishes the use case: preparing a confirmation draft for a sealed or sealing brief, with the human sending it later from their own STEMPA account. It does not explicitly compare this tool with sibling alternatives, but the exclusions ('sends nothing, emails nobody, records nothing') provide strong usage boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read-only: whether the counterparty confirmed or rejected a change you asked them to confirm. Each request of this account (for one version's content_hash, or all), newest first: title, version, status (sent, confirmed, rejected, expired, locked), sent_at, decided_at. It never shows the counterparty's address.
| Name | Required | Description | Default |
|---|---|---|---|
| content_hash | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds genuine value beyond them: newest-first ordering, the five distinct status values (sent, confirmed, rejected, expired, locked), and a privacy guarantee that the counterparty's address is never shown. This is materially richer than the annotations alone.
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 read-only constraint and core purpose are front-loaded, and the sentence enumerating status values and fields is dense but purposeful. Slightly run-on, but every clause conveys operative 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 an output schema present, the description needn't explain return structure, yet it still lists the emitted fields and ordering for orientation. Combined with the parameter scoping and status enumeration, an agent has enough to call this correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for the single optional content_hash parameter, so the description must carry the burden. It does: 'for one version's content_hash, or all' explains both what the parameter scopes to and the omit-for-all default, which the schema's null default alone does not convey.
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?
Opens with a specific verb+resource ('Read-only: whether the counterparty confirmed or rejected a change') and enumerates the returned fields, so the agent knows exactly what it retrieves. It does not explicitly contrast with the sibling confirmation_prepare, leaving that distinction to inference from the names.
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 by 'Read-only' and 'status,' suggesting it is the query counterpart to confirmation_prepare, but there is no explicit when-to-use/when-not statement or named alternative. The agent must infer that this is the read path versus the prepare path.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Record the person's answer to a question, or confirm or correct an assumption. confirm=true accepts an assumption as it is; answer text answers a question or corrects an assumption. Give exactly one.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| answer | No | ||
| confirm | No | ||
| dimension | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, idempotentHint=true and destructiveHint=false, so safety and repeatability are covered. The description adds the semantic distinction that confirm=true accepts an assumption unchanged while answer text overrides it, which is useful, but it does not say what happens on invalid input (both supplied, neither supplied, unknown id).
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 short sentences, front-loaded with the action and followed by the mode rule. Minor redundancy between the opening sentence and 'answer text answers a question or corrects an assumption', but nothing is wasted.
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?
An output schema exists, so return values needn't be described, and annotations cover the mutation profile. Still, for a four-parameter mutation tool with zero schema descriptions, the unexplained required 'dimension' parameter and vague 'id' leave a real gap in what an agent needs to call 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 0%, so the description must carry parameter meaning, and it only covers answer and confirm — though it does add genuine value by declaring they are mutually exclusive, which the schema does not encode. The required parameters id and dimension are never explained at all, leaving an agent unable to know what dimension refers to.
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 ('Record the person's answer') and separates the two modes: answering a question versus confirming/correcting an assumption. It doesn't differentiate itself from siblings like grill_skip or grill_gaps, but the action itself is 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?
'Give exactly one' gives a real selection rule between the answer and confirm parameters. However, it says nothing about when to call this versus grill_skip or grill_gaps, or what preconditions exist (e.g., must a grill session be active).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a frozen brief back, by its id or its fingerprint (content hash), with its title and client. It is checked against its fingerprint on every read, so what you read is exactly what was frozen.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | ||
| content_hash | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so the description is not carrying the safety burden. It does add genuinely non-obvious behavior: the content is re-verified against its fingerprint on every read. The gap is that it doesn't say what happens when verification fails (error vs. warning).
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 short sentences, front-loaded with the action, zero filler. Every clause contributes 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?
An output schema exists, so return-value explanation is not required; the brief mention of title and client is a bonus. The remaining incompleteness is the fingerprint-mismatch behavior and the id/content_hash requirement rule.
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 0%, so the description must compensate. It usefully explains that content_hash is the fingerprint (an alternative key to id), which the bare schema does not. However, both params default to null and it never states whether at least one is required or what happens if neither is supplied.
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 ('read a frozen brief back') and names the two lookup keys. It clearly differs from grill_list/grill_get in shape, though it never explicitly contrasts itself with those siblings.
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 — use this to retrieve an already-frozen brief — but there is no explicit guidance on when to prefer it over grill_get or grill_list, nor any stated precondition (e.g. that the brief must already be frozen).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Mark one thing the brief waits on as settled, saying how you know. Until it is settled the brief cannot be frozen; it never gets a default. Later checkpoints (with an owner and a stage) are not settled here.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| key | Yes | ||
| evidence | Yes | ||
| dimension | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the write, idempotent, non-destructive profile, and the description adds real behavioural context beyond them: the call requires justification ('saying how you know'), it gates freezing the brief, and no default is ever assumed. It stops short of describing failure modes, what evidence must look like, or what the response contains.
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 tight sentences, front-loaded with the action, then the consequence, then the exclusion. 'It never gets a default' is slightly cryptic but not wasted; 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?
The output schema covers return values and annotations cover safety, so the main remaining burden is the undocumented parameters and the opaque vocabulary. For a four-required-parameter mutation with no schema documentation, the description leaves a meaningful gap an agent must bridge by trial.
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 0% and all four parameters (id, key, dimension, evidence) are bare strings. The description only obliquely implies the evidence parameter via 'saying how you know' and says nothing about id, key, or dimension, leaving an agent to guess what identifies a dependency and what values dimension accepts.
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 verb 'mark ... as settled' and the resource 'one thing the brief waits on' identify a state transition on a dependency, which maps to the tool name. The final clause separates it from later checkpoint work. The phrasing is metaphorical ('the brief waits on', 'settled', 'never gets a default') rather than plainly saying 'dependency', so an agent must interpret the domain vocabulary.
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 a clear trigger ('until it is settled the brief cannot be frozen') and an explicit exclusion ('later checkpoints ... are not settled here'), which steers the agent away from misuse. It does not name an alternative tool (e.g. grill_answer, grill_skip, grill_freeze), so routing between siblings still requires inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Freeze the brief, only when the person asks. Refused while a section is empty, an important question is open, an assumption is unconfirmed, or a minor question has no default. A freeze is NOT a seal: the person seals the brief in their STEMPA account, and the answer says where.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly=false, idempotent=true, destructive=false), and the description adds the non-obvious part: the refusal preconditions that make the call fail in practice. It further discloses the scope boundary that this is not a seal, which is exactly the kind of semantic distinction an agent cannot recover from the schema.
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 action and the permission gate, then the refusal rules. Slightly awkward wrapping and the trailing 'the answer says where' is a touch cryptic, but no sentence is wasted.
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?
An output schema exists, so return values need not be spelled out, and the description still points the agent at where to find the sealing location. The only gap is the meaning of the id argument, which for a single-parameter state-transition tool is low risk.
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 1 parameter at 0% schema description coverage, the description never says what 'id' refers to (presumably the brief id), so the schema gap is not compensated. It is still close to self-evident given the title and the tight domain, so this is a minor rather than fatal omission.
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 (freeze) on a specific resource (the brief) and explicitly contrasts it with 'seal', which is the related but distinct action performed by the person in STEMPA. It does not name a sibling tool directly (e.g. grill_brief / grill_gaps), so differentiation from the toolset relies partly on inference from the precondition list.
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 an explicit gating condition ('only when the person asks') plus four concrete when-not conditions (empty section, open important question, unconfirmed assumption, minor question with no default). It also routes the agent to the alternative (sealing happens in the person's STEMPA account), leaving little to infer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The next questions to ask the person: the important ones first, at most 5, each with options, your recommendation and why. Also lists the assumptions to confirm and any section still empty.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so safety behavior is covered. The description adds useful output-shaping details—prioritization, a maximum of five items, included recommendations, assumptions, and empty sections—but does not add much beyond what the output schema likely covers.
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 tightly written sentences with no wasted words. It front-loads the main output and then adds secondary items, making it easy to scan.
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 read-only tool with rich annotations and an output schema, the description is adequate about returned content and limits. However, it leaves the required 'id' parameter semantically unexplained, which is a notable gap 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?
The schema has only one required parameter, 'id', with 0% description coverage, and the description never explains what that id identifies or how it should be supplied. The schema establishes that it is a required string, but the description does not compensate for the missing semantic 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 clearly states what the tool returns: the next questions to ask, prioritized, capped at five, with options, recommendation, and rationale, plus assumptions and empty sections. It is specific about content and scope, though it never explicitly distinguishes itself from sibling tools such as grill_answer or grill_brief.
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 provides no explicit guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. The phrase 'next questions to ask the person' implies a workflow context, but the description does not tell an agent when to choose this over siblings like grill_answer or grill_get.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read back one brief (in progress, frozen or skipped) with its sections, its text and its history.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds useful behavioral scope: it works across all three brief states and returns sections, text and history. It does not mention permissions, pagination or size of history.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One front-loaded sentence with no filler. It packs the resource, its states and the returned parts efficiently; the only weakness is the parenthetical state list interrupting the flow.
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?
An output schema exists, so return-value shape need not be explained, and the description still signals what is included (sections, text, history). For a simple single-parameter read tool this is close to complete; only the id format and error behavior for a missing brief are unaddressed.
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 0% and the single 'id' parameter has no documented meaning in either schema or description. The description implies the id selects 'one brief', which gives the agent minimal working semantics, but it does not say whether it is a numeric id, slug or UUID.
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 ('read back') and resource ('one brief') and enumerates what comes back: sections, text, history. It also names the possible states (in progress, frozen, skipped), which implicitly separates it from list/mutation siblings. It stops short of explicitly contrasting with grill_list.
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: retrieve a single brief by id. There is no explicit 'use this when you need the full content of one brief, use grill_list to enumerate briefs' routing, even though grill_list is a direct sibling that could be confused with it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List this account's briefs by title (and client, where given): in progress, frozen and skipped.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is free. The description still adds real value by enumerating which lifecycle states are returned (in progress, frozen, skipped), which is behavioral information not present in annotations, but it says nothing about scoping, permissions, or whether skipped items appear with status labels.
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 front-loaded sentence with no padding. The parenthetical '(and client, where given)' is slightly ambiguous about whether client filtering or display is meant, which keeps it from a 5.
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 zero-parameter read tool with full annotations and an output schema, little is strictly required, and the status enumeration is a useful addition. What is missing is routing context against the crowded sibling set – nothing tells the agent why to pick grill_list over stempa_briefs or grill_get.
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, which normally sets a baseline of 4, but the description instead spends its words describing the shape of the output ('by title (and client, where given)... in progress, frozen and skipped') rather than any call semantics. Since an output schema exists, that content is partly duplicative, leaving the parameter dimension as adequate-but-minimal.
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 ('List this account's briefs') and adds the dimensions of the listing (title, client) and the statuses covered. It does not distinguish itself from similarly named siblings such as stempa_briefs or grill_get, which an agent could easily confuse for this same listing capability.
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 only implied – the agent can infer 'call this to browse briefs' but there is no explicit when-to-use, no pointer to grill_get for detail retrieval, and no clarification against stempa_briefs. With 14 siblings and two other brief-related list-ish tools, that omission matters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fill in sections of the brief. Mark each KNOWN (say where you found it), INFERRED (an assumption the person confirms) or GAP (a question: say whether it is important (blocking), give 2-3 options, the one you recommend and why). A minor question may carry a default. All entries are saved together or none is.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| entries | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the write/destructive/idempotent profile, and the description adds a genuine behavioral trait beyond them: 'All entries are saved together or none is' discloses atomic all-or-nothing persistence. It does not explain why the operation is flagged destructive (e.g. whether it overwrites existing sections), which is the main remaining gap, but the atomicity disclosure is real added value.
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 core action is front-loaded in the first sentence, and the subsequent sentences each carry useful information (tag definitions, default allowance, atomic save). It is dense but not padded; every clause maps to a rule the caller needs.
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?
An output schema exists, so return values need not be explained, and the schema covers the complex nested fields. The description adequately frames the tagging workflow but omits what the required 'id' refers to and never mentions the structured dependencies/gates dimension, which is the most intricate part of the input.
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?
Although top-level schema coverage is 0%, the nested $defs are richly documented, and the description adds meaning that reinforces them: it maps 'say where you found it' to source, 'give 2-3 options' to options, 'the one you recommend and why' to lead/reason, and 'a minor question may carry a default' to default. The required 'id' parameter is never explained, which is the notable omission.
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 concrete verb and resource ('Fill in sections of the brief') and then clearly defines what the tool records via the KNOWN/INFERRED/GAP tagging model. An agent understands it is writing structured brief entries, but nothing distinguishes it from siblings like grill_brief, grill_answer or grill_gaps, so it falls 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?
Usage is implied by the tagging instructions (use this to record what you know, infer, or must ask), which gives an agent a sense of the call's purpose. However, there is no explicit statement of when to choose this over grill_answer or grill_gaps, and no preconditions are named, leaving the routing between tools to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Skip the questions: record the one-line assumptions you are working on and mark the brief SKIPPED (it stays visible).
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| assumptions | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this is a non-read-only, idempotent, non-destructive mutation. The description adds useful behavioral context by explaining that assumptions are recorded and the brief remains visible as SKIPPED, which helps an agent understand the effect.
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 efficient sentence that front-loads the core action and adds only necessary effect details. No sentence is wasted.
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 is simple, annotations cover safety/mutation traits, and an output schema exists, so the description does not need to explain return values. It gives enough context to understand the operation, though it could more explicitly document the required id parameter.
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 0%, so the description must carry parameter meaning. It explains that assumptions are one-line strings and implies the id refers to the brief being marked, but it does not explicitly name or describe the id parameter or clarify assumptions array constraints.
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 action: skip the questions, record assumptions, and mark the brief SKIPPED. It clearly distinguishes the tool from the answer-oriented sibling by emphasizing skipping rather than responding.
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 phrase 'Skip the questions' establishes a clear condition for use and implies an alternative to answering, though it does not explicitly name grill_answer or state exclusions. The context is sufficient but not fully explicit about when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start a new brief with the person. Returns its id, a line to say back to the person, and the empty sections to fill in.
profile: 'client-job' whenever the work is done for a client or customer (then also give `client`);
'general' for the person's own work. Left out, STEMPA picks one from the idea and says which.
'operating-profile' only when stempa_whoami offers it on this account.
amends: id of a frozen brief to change; makes a new linked version that starts from it.
| Name | Required | Description | Default |
|---|---|---|---|
| idea | Yes | ||
| title | No | A short human name for the brief, e.g. 'Kitchen refit for the Mokoena family' (one line, max 80). | |
| amends | No | ||
| client | No | Who the work is for (a company or person), when it is for someone else (one line, max 80). | |
| profile | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this is a non-readonly, non-idempotent, non-destructive mutation. The description adds useful behavior beyond that: it returns an id, a line to say back to the person, and empty sections, and it explains that amends creates a new linked version from a frozen brief rather than modifying it in place.
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 purpose and return values are front-loaded, followed by tightly scoped guidance for profile and amends. The formatting is slightly awkward with line breaks inside the description, but there is little wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has five parameters, one required, and an output schema, so the description does not need to explain return values in detail. However, for a creation tool it leaves the required `idea` parameter completely undefined and does not explain what the empty sections represent or how they will be filled in later.
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 40%, so the description must compensate. It does well for profile (explains each enum choice and fallback behavior) and amends (explains the linked-version semantics), but the required `idea` parameter is not described anywhere, leaving the most important input undefined.
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 a new brief'. It also says what it returns, which is useful. It does not explicitly contrast itself with siblings like grill_brief or grill_get, though 'new' distinguishes it from amendment via the amends parameter.
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 conditional guidance for profile values: 'client-job' when work is for a client, 'general' for own work, 'operating-profile' only when stempa_whoami offers it. It also explains when to use amends instead of a fresh brief. It does not mention alternatives among sibling tools, but the when-to-use conditions for the optional parameters are explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Log a feature request for the STEMPA team, ONLY after the person said yes to your offer
(confirmed_by_person true). text is what they want STEMPA to do, in their words, without names or contact
details (emails and phone numbers are removed). It changes nothing else: no act, no brief, no outcome.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | ||
| confirmed_by_person | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare a non-destructive write, but the description adds meaningful side-effect context: 'It changes nothing else: no act, no brief, no outcome.' It also discloses PII handling ('emails and phone numbers are removed'), which is valuable beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three compact sentences, front-loaded with the core action and prerequisite. Every sentence carries operational value: confirmation gate, content rules, and side-effect scope.
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 two-parameter write tool with annotations and an output schema, this is complete. It covers the prerequisite, content constraints, PII sanitization, and what is not changed, so the agent can call 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 description coverage is 0%, so the description must carry parameter meaning. It explains both parameters: `text` is 'what they want STEMPA to do, in their words' with names/contact details stripped, and `confirmed_by_person` must be true only after the person agreed.
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: 'Log a feature request for the STEMPA team'. The scope is clear and distinguishable from sibling confirmation/grill/stempa tools, none of which handle feature requests.
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 provides the when-to-use condition: 'ONLY after the person said yes to your offer (confirmed_by_person true)'. The word ONLY also supplies the exclusion condition, leaving little ambiguity for the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read-only: this account's sealed briefs, and the briefs waiting for the person's seal, each by title (and client, where given).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The 'Read-only:' prefix restates readOnlyHint and destructiveHint=false that the annotations already declare, so it earns no credit. The only extra content, that each item is shown 'by title (and client, where given)', duplicates what the output schema already documents. With annotations and an output schema both present, the description adds almost no behavioral 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?
It is one compact sentence with the core subject up front and no filler. The only wasted text is the redundant 'Read-only:' clause, which adds no information beyond the annotations.
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 output schema and annotations cover return values and safety, so the description does not need to repeat them. However, key domain language ('sealed briefs', 'the person's seal') is left undefined, and an agent cannot tell how sealing relates to the grill_freeze or stempa_receipt siblings. That vocabulary gap is the remaining thing the description should have closed.
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 there is nothing for the description to explain at the input level. The baseline of 4 applies; no parameter-related gap exists.
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?
It uses a specific verb-and-resource framing: it returns this account's sealed briefs plus briefs awaiting the person's seal, with title and client fields. That is more than a restatement of the title and clearly names two result sets. It stops short of distinguishing itself from the grill_* siblings or explaining what 'sealed' means in that vocabulary.
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 can only be inferred from the purpose: use it to see sealed briefs and seal-pending briefs. There is no explicit when-to-use, no exclusion, and no pointer to a sibling such as grill_list or stempa_receipt for overlapping needs. It is sufficient only because a zero-parameter listing tool has an obvious role.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read-only: call it when the person asks for something you have no STEMPA tool for. ask is what they want,
in a few words (no names or contact details). It answers what STEMPA can do about it: available (the tool to
use), plan_gated (the plan, price and link: say them once), blocked_by_rule (why, and what the person can
change) or not_a_feature (what STEMPA is, and the offer to log a feature request). It records nothing.
| Name | Required | Description | Default |
|---|---|---|---|
| ask | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly/idempotent/destructive/openWorld, yet the description still adds that 'It records nothing' and explains how each response branch should be handled. The four-state enumeration is genuinely behavioral, though it overlaps with the output schema that already 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-loaded trigger first, then the parameter, then the outcome taxonomy, then a closing non-mutation note. Dense and nearly waste-free; the final 'It records nothing' sentence is partly redundant with readOnlyHint but is short enough to earn 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?
For a one-parameter routing tool with an output schema, this covers trigger, parameter hygiene and every response branch an agent must act on. Nothing needed 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 coverage is 0% for the single parameter, so the description must compensate, and it does: `ask` is 'what they want, in a few words (no names or contact details)'. The privacy constraint is concrete, but the phrasing format is only loosely specified ('in a few words').
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a precise trigger ('when the person asks for something you have no STEMPA tool for') and enumerates the four answer states (available, plan_gated, blocked_by_rule, not_a_feature). That distinguishes it cleanly from every sibling: it is the fallback router, not a grilling, briefing or profile tool.
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 usage condition is stated as an explicit exclusion ('no STEMPA tool for'), which implies existing tools take precedence, and it describes what to do with each outcome ('say them once' for plan/price/link; offer to log a feature request for not_a_feature). Little is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read-only: the person's sealed operating profile (what they do, how they decide, what an assistant should always do, never do and ask first, how it should sound), released to this assistant only if the person approved it for their profile. Call it at the start of a chat, and whenever the person says 'load my STEMPA profile'. Every call is recorded. The lines are instructions the person asks you to follow; STEMPA does not enforce them. If the profile is not available, carry on without it.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (read-only, idempotent, non-destructive), it discloses authorization scoping ('released to this assistant only if the person approved it'), an audit consequence ('Every call is recorded'), and trust semantics ('The lines are instructions the person asks you to follow; STEMPA does not enforce them') — all material to how an agent should treat the output.
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 read-only status and the resource before triggers and caveats, and every sentence carries information. The long parenthetical enumerating profile sections makes one dense sentence, but removing it would lose real signal about payload content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema already exists, so return structure needn't be explained; the description instead supplies what the schema cannot — when to call, authorization condition, audit logging, and how to interpret the returned lines. Nothing needed 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?
The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline applies. No space is wasted on phantom parameter talk.
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?
Names a specific resource (the person's sealed operating profile) and enumerates its contents — behaviors, decision style, always/never/ask-first rules, tone — so the agent knows exactly what it retrieves. It is clearly distinct from siblings like stempa_whoami or stempa_briefs, which are not described as carrying the operating instructions.
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 trigger ('at the start of a chat'), a verbatim user utterance that should re-trigger it ('load my STEMPA profile'), and explicit when-not behavior ('If the profile is not available, carry on without it') rather than leaving the agent to invent a fallback.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read-only: the signed receipt of one SEALED brief (its title, who sealed it, when, its fingerprint, two signatures). It checks out offline; give the person the receipt link.
| Name | Required | Description | Default |
|---|---|---|---|
| content_hash | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint, idempotentHint, openWorldHint=false, and destructiveHint=false, and the description reinforces read-only behavior while adding that the receipt 'checks out offline' and lists its contents. This adds useful behavioral context beyond the annotations, though it does not discuss permissions or link lifetime.
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-loads the read-only nature, and includes only useful details about the receipt and offline verification. There is no redundant or filler language.
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 is simple, annotations are rich, and an output schema exists, so much of the behavioral and return-value context is already covered. However, the description omits any explanation of the required content_hash parameter, which is a meaningful gap 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 0%, so the description should compensate for the single required content_hash parameter. It never mentions content_hash or explains its format, source, or relationship to the 'fingerprint' mentioned in the receipt contents.
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 resource as the signed receipt of one sealed brief and enumerates the receipt contents, so an agent knows exactly what it retrieves. It does not explicitly distinguish itself from sibling tools such as stempa_briefs, but the singular 'one SEALED brief' scope is reasonably clear.
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 phrase 'give the person the receipt link' provides a post-retrieval usage hint, and 'one SEALED brief' implies it applies only to sealed briefs. However, it does not state when to use this tool instead of siblings like stempa_briefs or how to obtain the required hash, leaving usage guidance implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
What STEMPA is, in plain words (read about first and lead with it when the person asks what STEMPA
is), plus who this connection acts as, the account's plan, its seals this month, and the link where the
person seals what you froze.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered elsewhere. The description adds one piece of contextual behavior that annotations cannot: the returned link is where the user seals content the agent froze, which reveals the tool's role in the freeze/seal workflow, but it says nothing about auth requirements, freshness of 'this month' figures, or side effects of calling it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Everything is crammed into a single run-on sentence with an embedded parenthetical, so the most important instruction (call this to learn the acting identity) is not front-loaded. The content is largely substantive, but the structure forces the agent to parse three unrelated payloads out of one breath.
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 zero parameters, a full annotation set, and an output schema handling the return shape, the description only needs to say what class of data comes back — which it does (identity, plan, seals, seal link). The one residual gap is the dangling reference to an `about` tool/prompt that the agent has no way to locate.
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 there is nothing for the description to disambiguate beyond what the empty schema already shows. Baseline 4 applies; the description gains no extra credit here but loses none.
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 enumerates concrete outputs (identity of the acting account, plan, seals this month, a seal link) but the leading clause reframes the tool as an explainer of what STEMPA is, which sits oddly with the name 'Who am I' and with the sibling stempa_profile. An agent can guess the tool's job, but the bundling of product explainer + identity + usage stats makes the primary purpose ambiguous.
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?
One actionable condition is given ('read `about` first... when the person asks what STEMPA is'), but `about` does not appear in the sibling tool list, so the referenced counterpart is unresolvable from what the agent can see. There is no guidance on when to choose stempa_whoami over stempa_profile or stempa_briefs, which are the real next-best alternatives.
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.
confirmation_statusrequest_featurestempa_next_stepconfirmation_preparegrill_answergrill_briefgrill_dependencygrill_freezegrill_gapsgrill_getgrill_listgrill_mapgrill_skipgrill_startstempa_briefsstempa_profilestempa_receiptstempa_whoamiPrepare USPS Certified Mail letters from any AI assistant; a person reviews, pays and authorizes.
Signed verdict receipts recovering a fleet's gatekeeper category, plus appeal packets.
Your AI writes letters. We send them as real post to 31 countries, with status and e-mail updates.
One inbox for all your addresses: your AI agent reads, sorts, drafts and sends with your permission.
Add one secure layer between your agents and this server.