Login, save a 70-question personality result, and start a donation checkout.
Scored across 5 tools
Each tool targets a distinct action: fetching questions, listing donors, authenticating, scoring a test, and starting a donation. There is no meaningful overlap, and the descriptions clearly explain inputs and outputs (e.g. the token flow from login to score_personality_test).
Four of five tools follow a clean verb_noun pattern (get_personality_questions, list_donors, score_personality_test, start_donation). 'login' is a bare verb that breaks the pattern slightly but remains unambiguous.
Five tools reasonably cover the two sub-domains (personality test and donations). It is slightly lean, with the donation side represented by only two tools, but nothing feels redundant or excessive.
The personality test can be scored and saved, but there is no tool to retrieve a previously saved result or its history, and donations can be started but not checked for completion or managed. Essential create paths exist, yet read-back operations for saved results and gifts are missing.
Fetch the 70-question MakeChoice personality test. Each item has id, question, answer_a, and answer_b. mood is how the person feels right now: ang, plea, love, naug, hap, or sadd.
| Name | Required | Description | Default |
|---|---|---|---|
| mood | No | hap |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. 'Fetch' implies a safe read and it discloses the returned item fields, which is useful. But it never explains what effect 'mood' has on the questions returned (filtering? tone?), a key behavioral question for a test-retrieval tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences, front-loaded with the resource and count. The mood sentence is somewhat cramped 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?
It compensates for the absent output schema by listing the four item fields, which is the right call. However, it omits the default value, the effect of mood on output, and any prerequisite/sequencing relative to the sibling scoring tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It explains that mood represents the person's current feeling and enumerates the allowed codes — semantics the raw enum lacks — but it doesn't decode the abbreviations or mention the 'hap' default.
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: fetch the 70-question MakeChoice personality test, plus the shape of each item. It is clearly distinct from score_personality_test in practice, though it never names or contrasts the sibling explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance at all. It doesn't say whether this must be called before score_personality_test, nor under what conditions (e.g., before/after login) it applies, leaving the agent to infer the workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Public donor hall of fame for Changing Our Futures. Returns the newest gifts: name, about, amount, and date.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It discloses that the listing is public and ordered newest-first, which is genuinely useful, but says nothing about pagination, whether the result set is capped, or how the limit parameter affects behavior — a real gap for a list tool with no annotation coverage.
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 tight sentences with the scope and returned fields front-loaded; 'hall of fame' is mild flavor text but does not obscure the meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so naming the returned fields (name, about, amount, date) does useful work, but the description leaves the input parameter and result-size behavior undocumented, which for a tool whose only knob is limit is an incomplete picture.
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 single parameter (limit, default 10, max 50) has 0% schema description coverage, and the description never mentions it. The only partial compensation is naming returned fields, which are output-side, not the input 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 names the resource (public donor hall of fame / newest gifts) and the verb (Returns), so an agent knows this lists recent donations with the fields name, about, amount, and date. It is not differentiated against siblings, but the siblings (login, personality tests, start_donation) are far enough apart that confusion is unlikely.
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?
There is no statement of when to use this tool versus alternatives such as start_donation, no prerequisites, and no exclusions. The word 'Public' implies no auth is needed, but nothing tells the agent the selection context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Log in to Changing Our Futures / MakeChoice with the person's email and password. Returns access_token. Pass that token to score_personality_test. Do not repeat the password.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | |||
| password | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It does disclose the return payload (access_token) and a security behavior (do not repeat the password), which is genuinely useful. It does not cover failure modes, token validity/expiry, or credential requirements, so it is only partially complete.
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, each carrying distinct value (action, return value handoff, security constraint), with the core action front-loaded. 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?
For a two-parameter auth tool with no output schema and no annotations, the description covers the essentials: what it authenticates, what it returns, and how to use the result. Missing only error/expiry behavior, which is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate; it names both parameters and adds the meaningful constraint that the password is secret and must not be repeated. It still omits email format expectations (e.g. valid-email validation) and any credential policy details.
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 (log in) and resource (Changing Our Futures / MakeChoice) with the required credentials. It is immediately distinguishable from siblings like list_donors or start_donation, and names score_personality_test as the downstream consumer.
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 clear sequencing context: use this to obtain a token, then pass it to score_personality_test. There is no explicit statement of when-not to use it or what to do on failure, but the intended workflow is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Score the personality test and save it on the logged-in member. access_token comes from login. answers is 70 letters a or b in question order, or objects {id, answer}. A new result can be saved 30 days after the previous one. Returns personality_code, personality_name, characteristics, strengths, weaknesses, saved, and result_id.
| Name | Required | Description | Default |
|---|---|---|---|
| mood | No | hap | |
| answers | Yes | ||
| access_token | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and delivers: it is a mutating operation that persists a result to the logged-in member, requires an access_token sourced from login, and enforces a 30-day cooldown between saves. This is substantive behavioral context an agent could not infer 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?
Four tight sentences, front-loaded with the core action, then auth, input format, constraint, and returns. Nearly every clause earns its place, though the return-field list is long for a tool with no 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?
With no output schema and no annotations, the description usefully enumerates return fields (personality_code, personality_name, characteristics, etc.) and discloses the mutation and rate limit. The only meaningful gap is the undocumented mood 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 compensate. It does for answers (70 a/b letters in question order, or {id, answer} objects) and access_token (source), but the optional mood parameter with its enum is never mentioned, leaving one of three params undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('Score the personality test and save it on the logged-in member'), clearly distinguishing it from the read-only sibling get_personality_questions. An agent can identify the operation without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Points to the sibling tool for auth ('access_token comes from login') and states a hard usage constraint (a new result can only be saved 30 days after the previous one). It does not say when to prefer this over get_personality_questions, but the routing and precondition info is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start a gift to Changing Our Futures (EIN 47-1878490). Returns a Stripe Checkout url. The person still confirms and pays. amount is whole US dollars. one-time minimum is $1. monthly minimum is $50.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | one-time | |
| amount | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does real work: it discloses that the call returns a Stripe Checkout url and does not itself complete payment ('The person still confirms and pays'), plus the unit (whole US dollars) and per-type minimums. It omits auth/permission requirements and what happens on repeat calls, so it is not fully exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Short, front-loaded sentences with zero filler: identity, return value, payment flow, unit, then the two thresholds. Every sentence adds a fact an agent 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?
For a 2-param tool with no output schema and no annotations, the description covers the essentials — what it creates, what it returns, who completes payment, and value constraints. Missing only auth/prerequisite context and error or duplicate-handling 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 description coverage is 0%, so the description must compensate, and it does for the critical param: 'amount is whole US dollars', one-time minimum $1, monthly minimum $50 — semantics the integer/exclusiveMinimum-0 schema cannot express. The 'type' param is only addressed indirectly through the per-type minimums, relying on the enum to explain itself.
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 ('Start a gift') and resource (donation to Changing Our Futures, with EIN), and adds the returned artifact (Stripe Checkout url). No sibling tool (login, list_donors, personality tools) is even adjacent, so there is no ambiguity to resolve.
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 by the name and the natural reading of the description — there is no explicit 'use this when...' or alternative named. The line 'The person still confirms and pays' does implicitly scope it as the initiate step rather than a completion step, which gives partial guidance.
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.
get_personality_questionslist_donorsloginscore_personality_teststart_donationRead frozen Atlas cells, answer private quizzes, score Mini-IPIP vectors, and cast enum ballots.
Preflight utility evidence, open a $149 scan checkout, and file scoped buyer intake.
99-cent text pressure tests with human-confirmed checkout and paid-result retrieval.
Free open check: can an AI agent reach checkout on this store? Advisory; ARC stops before payment.
Add one secure layer between your agents and this server.