Someone to talk to, for your user: coaches, mentors, accountability partners. First session free.
Glama couldn't complete the latest health check. If this server requires authentication, missing or expired test credentials may be the cause. A test profile lets Glama authenticate for health checks and discover tools; it is separate from your personal connections.
If you are the author, claim ownership, then add or update a test profile under Admin → Test Profile.
Scored across 6 tools
Each tool targets a distinct action: sign-in start/finish, explanation, finding people, finding wagers, and proposing a wager. The two find_* tools are the closest pair, but their descriptions clearly separate people from wagers, so confusion is unlikely.
All tool names follow a consistent verb_noun pattern: begin_sign_in, finish_sign_in, explain_noemic, find_counterparties, find_relevant_wagers, propose_wager. The verb choice is clear and predictable.
Six tools is a well-scoped surface covering authentication, explanation, discovery, and wager drafting without redundancy or bloat. Each tool earns its place in the flow.
The core member journey is covered: sign in, understand the network, find wagers or counterparties, and create a draft wager. Publication and acceptance are intentionally left to the member via publishUrl, but there is no tool to list or manage one's own drafts, which is a minor gap.
Start the browser handoff required for personalized network reads or saving an unpublished wager draft. Show only signInUrl; keep requestId and pollSecret private. Never ask for credentials in chat.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With all annotations false, the description carries the behavioral burden. It discloses the browser handoff behavior, the need to keep requestId and pollSecret private, and the prohibition on asking for credentials in chat. This adds meaningful operational context 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?
The description is three short, purposeful sentences. It front-loads the core purpose, then immediately gives security-critical handling instructions. Every sentence earns its place and no content is redundant with the empty 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?
For a parameterless tool with no output schema, the description explains what the tool does, when it is needed, and how the agent should handle the returned values. Minor gap: it does not explicitly instruct calling finish_sign_in after the handoff, but this is arguably implied by the sibling tool and overall flow.
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 schema provides no semantic burden. The description correctly focuses on the tool's action and output handling instead of parameters, which is appropriate for a parameterless tool.
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 uses a specific verb ('Start the browser handoff') and resource ('Noemic sign-in'), and it clearly states the purpose: enabling personalized network reads or saving an unpublished wager draft. It also distinguishes itself from the sibling finish_sign_in by describing the initial step of the flow.
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 explicitly states when to use the tool: before personalized network reads or saving an unpublished wager draft. It also gives clear handling instructions (show only signInUrl, keep secrets private, never ask for credentials), though it does not explicitly name finish_sign_in as the follow-up tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Public, read-only explanation of Noemic's open direct wagering network, source provenance, human approval, and no-custody boundaries. Use when a person asks what Noemic is, why it can be trusted, or how matching works.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safe read-only nature is covered. The description adds value by specifying 'public', implying no authentication is needed, and by outlining the explanatory content, which helps set agent expectations about the response topic.
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 compact, with a front-loaded statement of the tool's nature and scope followed by direct usage guidance. Both sentences earn their place, and there is no redundant repetition of the title or 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?
Given the zero-parameter schema, the read-only/idempotent annotations, and the simple descriptive nature of the tool, the description covers what the tool does, what content it provides, and when to invoke it. No critical behavioral or usage information is missing for an AI agent to select and 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?
The tool has zero parameters and the schema description coverage is 100%, so there is no parameter ambiguity. The description appropriately avoids inventing parameter details and instead focuses on the tool's purpose, matching the baseline expected for a parameterless tool.
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 uses a specific verb ('explain') and a clear resource ('Noemic'), and enumerates the exact topics covered: the open direct wagering network, source provenance, human approval, and no-custody boundaries. It also distinguishes itself from sibling tools by explicitly labeling this a public, read-only explanation rather than an actionable betting or authentication operation.
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 clearly states when to use the tool: 'Use when a person asks what Noemic is, why it can be trusted, or how matching works.' It does not explicitly name alternatives or describe when not to use it, but the use cases are concrete and differentiate it well from the sibling action-oriented tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Secondary, read-only research for when the user explicitly asks to find a person for a concrete falsifiable forecast or disagreement, optionally anchored to an existing draft offer. Do not call proactively: the default wagering path recommends open wagers or useful questions instead of people. Results cite only scope-authorized evidence behind each match; weak results are clearly labeled.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| offerId | No | ||
| sessionToken | Yes | The private session token returned by finish_sign_in. Reuse it privately and never show it to the user. | |
| conversationContext | Yes | Only the relevant context from this conversation. Do not claim or imply that Noemic can read any conversation that was not supplied in this call. | |
| explicitUserRequest | Yes | Confirm that the user directly asked to search for counterparties. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive behavior. The description adds value by disclosing that results cite only scope-authorized evidence and that weak results are clearly labeled, which is useful beyond what annotations state.
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 deliver the essential context in order: what the tool is, when it must not be called, and what the results look like. There is no filler or unnecessary repetition of schema fields.
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-only research tool with no output schema, the description covers selection criteria, invocation timing, optional offer anchoring, and output behavior. The annotations and parameter schemas fill the remaining safety and input requirements, so the agent has enough to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning to offerId by calling it an optional anchor to an existing draft offer and connects explicitUserRequest to the stated requirement that the user explicitly asked. Limit is self-explanatory from its min/max constraints, and sessionToken/conversationContext are already described in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific action and resource: find a person for a concrete falsifiable forecast or disagreement, optionally anchored to an existing draft offer. It clearly distinguishes itself from siblings like find_relevant_bets by framing the task as people-finding rather than bet-finding.
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 trigger conditions: only when the user explicitly asks to find a person for a concrete falsifiable forecast or disagreement. It also gives a strong negative rule ('Do not call proactively') and points to the default alternative path, so the agent knows when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read-only ranking of open wager offers for the signed-in user. The model may call this proactively when the current conversation contains a concrete falsifiable forecast, measurable disagreement, or explicit desire to wager. Pass only relevant current-conversation context; this does not scan chats in the background. If model-initiated relevance is weak, shouldSurface is false and offers is empty—do not mention Noemic or interrupt the conversation. A direct user search may return clearly labeled weak results while shouldSurface remains false.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| sessionToken | Yes | The private session token returned by finish_sign_in. Reuse it privately and never show it to the user. | |
| conversationContext | No | Only the relevant context from this conversation. Do not claim or imply that Noemic can read any conversation that was not supplied in this call. | |
| explicitUserRequest | No | True only when the user directly asked to search open offers. Leave false for model-initiated ambient checks. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint and idempotentHint annotations, the description discloses that it does not scan chats in the background, that weak model-initiated relevance yields shouldSurface=false and empty offers, and that the model should not mention Noemic or interrupt the conversation in that case. This is meaningful behavioral context annotations do not provide.
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 compact and front-loaded with the core purpose, then folds in trigger conditions and critical behavioral caveats. Every sentence adds value and no information is repeated from the schema or 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?
For a tool with no output schema, the description usefully explains the shouldSurface and offers fields under weak relevance. It also covers proactive vs. user-initiated invocation and the privacy boundary around conversationContext. Minor gaps remain about the shape of individual offer entries and how ranking is determined, but the essentials for correct invocation are present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 75%, so the schema already explains sessionToken and conversationContext. The description adds important parameter-level semantics: conversationContext must contain only relevant supplied context and must not imply background scanning, and explicitUserRequest maps to direct user search versus model-initiated checks. limit is not mentioned, but its schema is self-explanatory.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: a read-only ranking of open wager offers for the signed-in user. This clearly distinguishes the tool from siblings like find_counterparties and propose_wager, and the title reinforces the 'strongly relevant' scope.
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 trigger conditions for proactive use: concrete falsifiable forecast, measurable disagreement, or explicit desire to wager. It also explains the difference between model-initiated and direct-user-search behavior, though it does not explicitly name alternative tools or state when to prefer them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Exchange the private requestId and pollSecret after browser approval. Pending means the person has not approved yet; complete returns a private sessionToken. Never expose these secrets.
| Name | Required | Description | Default |
|---|---|---|---|
| requestId | Yes | ||
| pollSecret | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond annotations by explaining that a 'pending' result means the user hasn't approved, and a 'complete' result yields a private sessionToken. It also warns to never expose the secrets, adding security-relevant behavior.
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 three concise sentences, front-loaded with the action, and includes a necessary security warning. Every sentence earns its place without redundancy.
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 covers the main outcomes (pending/complete) and the returned sessionToken, which is adequate for a sign-in completion tool. It doesn't discuss error cases, but the core context is sufficiently complete.
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 compensates by identifying both parameters (requestId, pollSecret) and indicating they are private secrets exchanged in the process. It doesn't detail each parameter individually but adds meaning beyond the bare 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 clearly states the tool's function: exchanging private requestId and pollSecret to complete a sign-in. It specifies the resources involved and the action, distinguishing it from sibling tools like begin_sign_in.
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 states the tool should be used 'after browser approval' and explains the pending vs. complete outcomes, guiding when to call. It doesn't explicitly name alternatives, but the sign-in flow context makes the usage clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fill in a wager exactly as the member would on the New wager form, when the user wants to formalize a concrete falsifiable forecast or disagreement. A wager is a title, an optional subtitle, the member's side, and the resolve time. Noemic writes the resolution terms itself and they are the same for every wager, so never ask the user for a decision rule, an evidence source, or void rules, and never put any of them in the title or the subtitle. The result is a private draft plus a publishUrl: the member opens it, sees the completed form, and publishes with one click. The model may suggest this naturally, but must not silently persist a passing remark. An exact source must be linked by an existing sourceRecordId, and an ID, a quote, or provenance must never be invented. This tool never publishes, invites, accepts, charges, escrows, or binds anyone.
| Name | Required | Description | Default |
|---|---|---|---|
| side | Yes | Whether the signed-in user takes Yes or No on the title. | |
| title | Yes | The wager as a question or claim a reader takes in at a glance. Nine words or fewer; Noemic refuses longer titles. | |
| subtitle | No | One line under the title saying what the title means, in the user's words. Optional. Not a decision rule, evidence source, or void rule: Noemic writes those. | |
| resolutionAt | Yes | The resolve time as ISO 8601 with a timezone offset. | |
| sessionToken | Yes | The private session token returned by finish_sign_in. Reuse it privately and never show it to the user. | |
| stakeDollars | No | Optional proposed stake in US dollars. It is draft text only; Noemic does not charge or hold it. | |
| sourceRecordId | No | An existing Noemic source record containing the literal source and provenance. Omit when none exists; never fabricate it or substitute a paraphrase. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description discloses that the result is a private draft plus publishUrl, that the tool never publishes/invites/accepts/charges/escrows/binds anyone, and that sourceRecordId must reference an existing source with no invented IDs, quotes, or provenance. This meaningfully supplements the sparse annotation booleans and aligns with readOnlyHint=false.
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 dense but every sentence earns its place: purpose, definition, constraints, result shape, non-persistence caveat, source-provenance rule, and side-effect disclaimer. The core verb and trigger are front-loaded, and there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 7 parameters and no output schema, the description still conveys what an agent needs to know: what the tool produces, what the user will do with the publishUrl, what must never be invented, and what side effects it does not have. The schema already covers the per-field input details.
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. The description adds useful cross-parameter constraints: title and subtitle must not contain resolution terms, sourceRecordId must be an existing source, and stakeDollars is draft-only. It does not redefine per-field syntax but does clarify intent 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 uses a specific verb and resource: 'Fill in a wager exactly as the member would on the New wager form.' It also states the precise trigger ('formalize a concrete falsifiable forecast or disagreement'), making it unmistakable from siblings like explain_noemic or find_relevant_wagers.
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 says when to use the tool and when not to: use it when the user wants to formalize a forecast or disagreement, 'must not silently persist a passing remark,' and must never ask for decision rules, evidence sources, or void rules. This gives an agent clear selection and rejection criteria.
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.
propose_wager11 fields changedInput schema / properties / propositionRemoved value: -{
- "description": "The concrete proposition that will be resolved.",
- "minLength": 15,
- "type": "string"
-}Input schema / properties / resolutionAt / descriptionPrevious value: -"The resolution time as ISO 8601 with a timezone offset."New value: +"The resolve time as ISO 8601 with a timezone offset."Input schema / properties / resolutionRulesRemoved value: -{
- "description": "The exact rule for deciding the outcome.",
- "minLength": 15,
- "type": "string"
-}Input schema / properties / resolutionSourceRemoved value: -{
- "description": "The authoritative source used to determine the outcome.",
- "minLength": 3,
- "type": "string"
-}Input schema / properties / resolverAdapterRemoved value: -{
- "description": "The resolver class selected before approval. Defaults to Noemic house review; naming a class does not connect an external service.",
- "enum": [
- "house",
- "objective_source",
- "external_oracle",
- "named_arbitrator"
- ],
- "type": "string"
-}Input schema / properties / side / descriptionPrevious value: -"Whether the signed-in user takes Yes or No on the proposition."New value: +"Whether the signed-in user takes Yes or No on the title."Input schema / properties / subtitleAdded value: +{
+ "description": "One line under the title saying what the title means, in the user's words. Optional. Not a decision rule, evidence source, or void rule: Noemic writes those.",
+ "maxLength": 200,
+ "type": "string"
+}Input schema / properties / title / descriptionAdded value: +"The wager as a question or claim a reader takes in at a glance. Nine words or fewer; Noemic refuses longer titles."Input schema / properties / title / minLengthPrevious value: -5New value: +3Input schema / properties / voidRulesRemoved value: -{
- "description": "The exact conditions under which the offer is void.",
- "minLength": 5,
- "type": "string"
-}Input schema / requiredPrevious value: -[
- "sessionToken",
- "title",
- "proposition",
- "side",
- "resolutionAt",
- "resolutionSource",
- "resolutionRules",
- "voidRules"
-]New value: +[
+ "sessionToken",
+ "title",
+ "side",
+ "resolutionAt"
+]propose_wager5 fields changedInput schema / properties / counterSideRemoved value: -{
- "description": "The compatible opposing side offered to a counterparty.",
- "minLength": 1,
- "type": "string"
-}Input schema / properties / side / descriptionPrevious value: -"The outcome or side the signed-in user proposes to take."New value: +"Whether the signed-in user takes Yes or No on the proposition."Input schema / properties / side / enumAdded value: +[
+ "yes",
+ "no"
+]Input schema / properties / side / minLengthRemoved value: -1Input schema / requiredPrevious value: -[
- "sessionToken",
- "title",
- "proposition",
- "side",
- "counterSide",
- "resolutionAt",
- "resolutionSource",
- "resolutionRules",
- "voidRules"
-]New value: +[
+ "sessionToken",
+ "title",
+ "proposition",
+ "side",
+ "resolutionAt",
+ "resolutionSource",
+ "resolutionRules",
+ "voidRules"
+]find_relevant_betsfind_relevant_wagerspropose_betpropose_wagerfind_counterparties3 fields changedInput schema / properties / explicitUserRequest / constAdded value: +trueInput schema / properties / explicitUserRequest / descriptionPrevious value: -"True only when the user directly asked to search for counterparties. Leave false for model-initiated ambient checks."New value: +"Confirm that the user directly asked to search for counterparties."Input schema / requiredPrevious value: -[
- "sessionToken",
- "conversationContext"
-]New value: +[
+ "sessionToken",
+ "conversationContext",
+ "explicitUserRequest"
+]add_availabilityadd_to_my_corpusartifact_libraryassign_artifactbecome_availablebegin_sign_in1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"book_nowbook_sessioncancel_bookingcheck_messagesclose_briefcoaching_playbookcomplete_assignmentcomplete_sessioncreate_artifactcreate_commitmentexplain_noemicfile_brieffind_counterpartiesfind_relevant_betsfinish_sign_in2 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesRemoved value: -falseget_availabilityget_personget_startedlist_peoplelogoutmatch_memy_artifactsmy_assignmentsmy_bookingsmy_briefsmy_coachingmy_commitmentsmy_connectionsmy_creditsmy_introsmy_profileopen_briefsport_contextpropose_betresolve_commitmentrespond_introsend_cuesend_introsend_messagesession_debriefsession_transcriptset_available_nowshow_peopleupdate_my_profilewrite_debriefadd_availability1 field changedInput schema / properties / sessionToken / descriptionPrevious value: -"The session token returned by login or register — proves which user is acting. Reuse it for the whole conversation; never a raw email."New value: +"The private session token returned by finish_sign_in. Reuse it for the conversation and never show it to the user."add_to_my_corpus1 field changedInput schema / properties / sessionToken / descriptionPrevious value: -"The session token returned by login or register — proves which user is acting. Reuse it for the whole conversation; never a raw email."New value: +"The private session token returned by finish_sign_in. Reuse it for the conversation and never show it to the user."assign_artifact1 field changedInput schema / properties / sessionToken / descriptionPrevious value: -"The session token returned by login or register — proves which user is acting. Reuse it for the whole conversation; never a raw email."New value: +"The private session token returned by finish_sign_in. Reuse it for the conversation and never show it to the user."become_available1 field changedInput schema / properties / sessionToken / descriptionPrevious value: -"The session token returned by login or register — proves which user is acting. Reuse it for the whole conversation; never a raw email."New value: +"The private session token returned by finish_sign_in. Reuse it for the conversation and never show it to the user."begin_sign_inbook_now1 field changedInput schema / properties / sessionToken / descriptionPrevious value: -"The session token returned by login or register — proves which user is acting. Reuse it for the whole conversation; never a raw email."New value: +"The private session token returned by finish_sign_in. Reuse it for the conversation and never show it to the user."book_session1 field changedInput schema / properties / sessionToken / descriptionPrevious value: -"The session token returned by login or register — proves which user is acting. Reuse it for the whole conversation; never a raw email."New value: +"The private session token returned by finish_sign_in. Reuse it for the conversation and never show it to the user."cancel_booking1 field changedInput schema / properties / sessionToken / descriptionPrevious value: -"The session token returned by login or register — proves which user is acting. Reuse it for the whole conversation; never a raw email."New value: +"The private session token returned by finish_sign_in. Reuse it for the conversation and never show it to the user."check_messages1 field changedInput schema / properties / sessionToken / descriptionPrevious value: -"The session token returned by login or register — proves which user is acting. Reuse it for the whole conversation; never a raw email."New value: +"The private session token returned by finish_sign_in. Reuse it for the conversation and never show it to the user."close_brief1 field changedInput schema / properties / sessionToken / descriptionPrevious value: -"The session token returned by login or register — proves which user is acting. Reuse it for the whole conversation; never a raw email."New value: +"The private session token returned by finish_sign_in. Reuse it for the conversation and never show it to the user."complete_assignment1 field changedInput schema / properties / sessionToken / descriptionPrevious value: -"The session token returned by login or register — proves which user is acting. Reuse it for the whole conversation; never a raw email."New value: +"The private session token returned by finish_sign_in. Reuse it for the conversation and never show it to the user."complete_session1 field changedInput schema / properties / sessionToken / descriptionPrevious value: -"The session token returned by login or register — proves which user is acting. Reuse it for the whole conversation; never a raw email."New value: +"The private session token returned by finish_sign_in. Reuse it for the conversation and never show it to the user."create_artifact1 field changedInput schema / properties / sessionToken / descriptionPrevious value: -"The session token returned by login or register — proves which user is acting. Reuse it for the whole conversation; never a raw email."New value: +"The private session token returned by finish_sign_in. Reuse it for the conversation and never show it to the user."create_commitment1 field changedInput schema / properties / sessionToken / descriptionPrevious value: -"The session token returned by login or register — proves which user is acting. Reuse it for the whole conversation; never a raw email."New value: +"The private session token returned by finish_sign_in. Reuse it for the conversation and never show it to the user."file_brief1 field changedInput schema / properties / sessionToken / descriptionPrevious value: -"The session token returned by login or register — proves which user is acting. Reuse it for the whole conversation; never a raw email."New value: +"The private session token returned by finish_sign_in. Reuse it for the conversation and never show it to the user."finish_sign_inloginlogout1 field changedInput schema / properties / sessionToken / descriptionPrevious value: -"The session token returned by login or register — proves which user is acting. Reuse it for the whole conversation; never a raw email."New value: +"The private session token returned by finish_sign_in. Reuse it for the conversation and never show it to the user."match_me1 field changedInput schema / properties / limit / maximumPrevious value: -20New value: +3my_artifacts1 field changedInput schema / properties / sessionToken / descriptionPrevious value: -"The session token returned by login or register — proves which user is acting. Reuse it for the whole conversation; never a raw email."New value: +"The private session token returned by finish_sign_in. Reuse it for the conversation and never show it to the user."my_assignments1 field changedInput schema / properties / sessionToken / descriptionPrevious value: -"The session token returned by login or register — proves which user is acting. Reuse it for the whole conversation; never a raw email."New value: +"The private session token returned by finish_sign_in. Reuse it for the conversation and never show it to the user."my_bookings1 field changedInput schema / properties / sessionToken / descriptionPrevious value: -"The session token returned by login or register — proves which user is acting. Reuse it for the whole conversation; never a raw email."New value: +"The private session token returned by finish_sign_in. Reuse it for the conversation and never show it to the user."my_briefs1 field changedInput schema / properties / sessionToken / descriptionPrevious value: -"The session token returned by login or register — proves which user is acting. Reuse it for the whole conversation; never a raw email."New value: +"The private session token returned by finish_sign_in. Reuse it for the conversation and never show it to the user."my_coaching1 field changedInput schema / properties / sessionToken / descriptionPrevious value: -"The session token returned by login or register — proves which user is acting. Reuse it for the whole conversation; never a raw email."New value: +"The private session token returned by finish_sign_in. Reuse it for the conversation and never show it to the user."my_commitments1 field changedInput schema / properties / sessionToken / descriptionPrevious value: -"The session token returned by login or register — proves which user is acting. Reuse it for the whole conversation; never a raw email."New value: +"The private session token returned by finish_sign_in. Reuse it for the conversation and never show it to the user."my_connections1 field changedInput schema / properties / sessionToken / descriptionPrevious value: -"The session token returned by login or register — proves which user is acting. Reuse it for the whole conversation; never a raw email."New value: +"The private session token returned by finish_sign_in. Reuse it for the conversation and never show it to the user."my_credits1 field changedInput schema / properties / sessionToken / descriptionPrevious value: -"The session token returned by login or register — proves which user is acting. Reuse it for the whole conversation; never a raw email."New value: +"The private session token returned by finish_sign_in. Reuse it for the conversation and never show it to the user."my_intros1 field changedInput schema / properties / sessionToken / descriptionPrevious value: -"The session token returned by login or register — proves which user is acting. Reuse it for the whole conversation; never a raw email."New value: +"The private session token returned by finish_sign_in. Reuse it for the conversation and never show it to the user."my_profile1 field changedInput schema / properties / sessionToken / descriptionPrevious value: -"The session token returned by login or register — proves which user is acting. Reuse it for the whole conversation; never a raw email."New value: +"The private session token returned by finish_sign_in. Reuse it for the conversation and never show it to the user."port_context1 field changedInput schema / properties / sessionToken / descriptionPrevious value: -"The session token returned by login or register — proves which user is acting. Reuse it for the whole conversation; never a raw email."New value: +"The private session token returned by finish_sign_in. Reuse it for the conversation and never show it to the user."registerresolve_commitment1 field changedInput schema / properties / sessionToken / descriptionPrevious value: -"The session token returned by login or register — proves which user is acting. Reuse it for the whole conversation; never a raw email."New value: +"The private session token returned by finish_sign_in. Reuse it for the conversation and never show it to the user."respond_intro1 field changedInput schema / properties / sessionToken / descriptionPrevious value: -"The session token returned by login or register — proves which user is acting. Reuse it for the whole conversation; never a raw email."New value: +"The private session token returned by finish_sign_in. Reuse it for the conversation and never show it to the user."send_cue1 field changedInput schema / properties / sessionToken / descriptionPrevious value: -"The session token returned by login or register — proves which user is acting. Reuse it for the whole conversation; never a raw email."New value: +"The private session token returned by finish_sign_in. Reuse it for the conversation and never show it to the user."send_intro1 field changedInput schema / properties / sessionToken / descriptionPrevious value: -"The session token returned by login or register — proves which user is acting. Reuse it for the whole conversation; never a raw email."New value: +"The private session token returned by finish_sign_in. Reuse it for the conversation and never show it to the user."send_message1 field changedInput schema / properties / sessionToken / descriptionPrevious value: -"The session token returned by login or register — proves which user is acting. Reuse it for the whole conversation; never a raw email."New value: +"The private session token returned by finish_sign_in. Reuse it for the conversation and never show it to the user."session_debrief1 field changedInput schema / properties / sessionToken / descriptionPrevious value: -"The session token returned by login or register — proves which user is acting. Reuse it for the whole conversation; never a raw email."New value: +"The private session token returned by finish_sign_in. Reuse it for the conversation and never show it to the user."session_transcript1 field changedInput schema / properties / sessionToken / descriptionPrevious value: -"The session token returned by login or register — proves which user is acting. Reuse it for the whole conversation; never a raw email."New value: +"The private session token returned by finish_sign_in. Reuse it for the conversation and never show it to the user."set_available_now1 field changedInput schema / properties / sessionToken / descriptionPrevious value: -"The session token returned by login or register — proves which user is acting. Reuse it for the whole conversation; never a raw email."New value: +"The private session token returned by finish_sign_in. Reuse it for the conversation and never show it to the user."set_passwordshow_peopleupdate_my_profile1 field changedInput schema / properties / sessionToken / descriptionPrevious value: -"The session token returned by login or register — proves which user is acting. Reuse it for the whole conversation; never a raw email."New value: +"The private session token returned by finish_sign_in. Reuse it for the conversation and never show it to the user."write_debrief1 field changedInput schema / properties / sessionToken / descriptionPrevious value: -"The session token returned by login or register — proves which user is acting. Reuse it for the whole conversation; never a raw email."New value: +"The private session token returned by finish_sign_in. Reuse it for the conversation and never show it to the user."add_availability3 fields changedInput schema / properties / emailRemoved value: -{
- "description": "The user's email — their identity on Noemic",
- "format": "email",
- "type": "string"
-}Input schema / properties / sessionTokenAdded value: +{
+ "description": "The session token returned by login or register — proves which user is acting. Reuse it for the whole conversation; never a raw email.",
+ "minLength": 16,
+ "type": "string"
+}Input schema / requiredPrevious value: -[
- "email",
- "slots"
-]New value: +[
+ "sessionToken",
+ "slots"
+]add_to_my_corpus3 fields changedInput schema / properties / emailRemoved value: -{
- "description": "The user's email — their identity on Noemic",
- "format": "email",
- "type": "string"
-}Input schema / properties / sessionTokenAdded value: +{
+ "description": "The session token returned by login or register — proves which user is acting. Reuse it for the whole conversation; never a raw email.",
+ "minLength": 16,
+ "type": "string"
+}Input schema / requiredPrevious value: -[
- "email",
- "text"
-]New value: +[
+ "sessionToken",
+ "text"
+]assign_artifact3 fields changedInput schema / properties / emailRemoved value: -{
- "description": "The user's email — their identity on Noemic",
- "format": "email",
- "type": "string"
-}Input schema / properties / sessionTokenAdded value: +{
+ "description": "The session token returned by login or register — proves which user is acting. Reuse it for the whole conversation; never a raw email.",
+ "minLength": 16,
+ "type": "string"
+}Input schema / requiredPrevious value: -[
- "email",
- "connectionId",
- "artifactId"
-]New value: +[
+ "sessionToken",
+ "connectionId",
+ "artifactId"
+]become_available3 fields changedInput schema / properties / emailRemoved value: -{
- "description": "The user's email — their identity on Noemic",
- "format": "email",
- "type": "string"
-}Input schema / properties / sessionTokenAdded value: +{
+ "description": "The session token returned by login or register — proves which user is acting. Reuse it for the whole conversation; never a raw email.",
+ "minLength": 16,
+ "type": "string"
+}Input schema / requiredPrevious value: -[
- "email",
- "displayName",
- "headline",
- "story"
-]New value: +[
+ "sessionToken",
+ "displayName",
+ "headline",
+ "story"
+]book_now3 fields changedInput schema / properties / emailRemoved value: -{
- "description": "The user's email — their identity on Noemic",
- "format": "email",
- "type": "string"
-}Input schema / properties / sessionTokenAdded value: +{
+ "description": "The session token returned by login or register — proves which user is acting. Reuse it for the whole conversation; never a raw email.",
+ "minLength": 16,
+ "type": "string"
+}Input schema / requiredPrevious value: -[
- "email",
- "profileId"
-]New value: +[
+ "sessionToken",
+ "profileId"
+]book_session3 fields changedInput schema / properties / emailRemoved value: -{
- "description": "The user's email — their identity on Noemic",
- "format": "email",
- "type": "string"
-}Input schema / properties / sessionTokenAdded value: +{
+ "description": "The session token returned by login or register — proves which user is acting. Reuse it for the whole conversation; never a raw email.",
+ "minLength": 16,
+ "type": "string"
+}Input schema / requiredPrevious value: -[
- "email",
- "profileId",
- "slotId"
-]New value: +[
+ "sessionToken",
+ "profileId",
+ "slotId"
+]cancel_booking2 fields changedInput schema / properties / sessionTokenAdded value: +{
+ "description": "The session token returned by login or register — proves which user is acting. Reuse it for the whole conversation; never a raw email.",
+ "minLength": 16,
+ "type": "string"
+}Input schema / requiredPrevious value: -[
- "bookingId"
-]New value: +[
+ "sessionToken",
+ "bookingId"
+]check_messages3 fields changedInput schema / properties / emailRemoved value: -{
- "description": "The user's email — their identity on Noemic",
- "format": "email",
- "type": "string"
-}Input schema / properties / sessionTokenAdded value: +{
+ "description": "The session token returned by login or register — proves which user is acting. Reuse it for the whole conversation; never a raw email.",
+ "minLength": 16,
+ "type": "string"
+}Input schema / requiredPrevious value: -[
- "email"
-]New value: +[
+ "sessionToken"
+]close_brief3 fields changedInput schema / properties / emailRemoved value: -{
- "description": "The user's email — their identity on Noemic",
- "format": "email",
- "type": "string"
-}Input schema / properties / sessionTokenAdded value: +{
+ "description": "The session token returned by login or register — proves which user is acting. Reuse it for the whole conversation; never a raw email.",
+ "minLength": 16,
+ "type": "string"
+}Input schema / requiredPrevious value: -[
- "email",
- "briefId"
-]New value: +[
+ "sessionToken",
+ "briefId"
+]complete_assignment3 fields changedInput schema / properties / emailRemoved value: -{
- "description": "The user's email — their identity on Noemic",
- "format": "email",
- "type": "string"
-}Input schema / properties / sessionTokenAdded value: +{
+ "description": "The session token returned by login or register — proves which user is acting. Reuse it for the whole conversation; never a raw email.",
+ "minLength": 16,
+ "type": "string"
+}Input schema / requiredPrevious value: -[
- "email",
- "assignmentId",
- "result"
-]New value: +[
+ "sessionToken",
+ "assignmentId",
+ "result"
+]complete_session2 fields changedInput schema / properties / sessionTokenAdded value: +{
+ "description": "The session token returned by login or register — proves which user is acting. Reuse it for the whole conversation; never a raw email.",
+ "minLength": 16,
+ "type": "string"
+}Input schema / requiredPrevious value: -[
- "bookingId"
-]New value: +[
+ "sessionToken",
+ "bookingId"
+]create_artifact3 fields changedInput schema / properties / emailRemoved value: -{
- "description": "The user's email — their identity on Noemic",
- "format": "email",
- "type": "string"
-}Input schema / properties / sessionTokenAdded value: +{
+ "description": "The session token returned by login or register — proves which user is acting. Reuse it for the whole conversation; never a raw email.",
+ "minLength": 16,
+ "type": "string"
+}Input schema / requiredPrevious value: -[
- "email",
- "title",
- "description",
- "script"
-]New value: +[
+ "sessionToken",
+ "title",
+ "description",
+ "script"
+]create_commitment3 fields changedInput schema / properties / emailRemoved value: -{
- "description": "The user's email — their identity on Noemic",
- "format": "email",
- "type": "string"
-}Input schema / properties / sessionTokenAdded value: +{
+ "description": "The session token returned by login or register — proves which user is acting. Reuse it for the whole conversation; never a raw email.",
+ "minLength": 16,
+ "type": "string"
+}Input schema / requiredPrevious value: -[
- "email",
- "title",
- "deadline",
- "stakeDollars"
-]New value: +[
+ "sessionToken",
+ "title",
+ "deadline",
+ "stakeDollars"
+]file_brief3 fields changedInput schema / properties / emailRemoved value: -{
- "description": "The user's email — their identity on Noemic",
- "format": "email",
- "type": "string"
-}Input schema / properties / sessionTokenAdded value: +{
+ "description": "The session token returned by login or register — proves which user is acting. Reuse it for the whole conversation; never a raw email.",
+ "minLength": 16,
+ "type": "string"
+}Input schema / requiredPrevious value: -[
- "email",
- "need"
-]New value: +[
+ "sessionToken",
+ "need"
+]loginlogoutmy_artifacts3 fields changedInput schema / properties / emailRemoved value: -{
- "description": "The user's email — their identity on Noemic",
- "format": "email",
- "type": "string"
-}Input schema / properties / sessionTokenAdded value: +{
+ "description": "The session token returned by login or register — proves which user is acting. Reuse it for the whole conversation; never a raw email.",
+ "minLength": 16,
+ "type": "string"
+}Input schema / requiredPrevious value: -[
- "email"
-]New value: +[
+ "sessionToken"
+]my_assignments3 fields changedInput schema / properties / emailRemoved value: -{
- "description": "The user's email — their identity on Noemic",
- "format": "email",
- "type": "string"
-}Input schema / properties / sessionTokenAdded value: +{
+ "description": "The session token returned by login or register — proves which user is acting. Reuse it for the whole conversation; never a raw email.",
+ "minLength": 16,
+ "type": "string"
+}Input schema / requiredPrevious value: -[
- "email"
-]New value: +[
+ "sessionToken"
+]my_bookings3 fields changedInput schema / properties / emailRemoved value: -{
- "description": "The user's email — their identity on Noemic",
- "format": "email",
- "type": "string"
-}Input schema / properties / sessionTokenAdded value: +{
+ "description": "The session token returned by login or register — proves which user is acting. Reuse it for the whole conversation; never a raw email.",
+ "minLength": 16,
+ "type": "string"
+}Input schema / requiredPrevious value: -[
- "email"
-]New value: +[
+ "sessionToken"
+]my_briefs3 fields changedInput schema / properties / emailRemoved value: -{
- "description": "The user's email — their identity on Noemic",
- "format": "email",
- "type": "string"
-}Input schema / properties / sessionTokenAdded value: +{
+ "description": "The session token returned by login or register — proves which user is acting. Reuse it for the whole conversation; never a raw email.",
+ "minLength": 16,
+ "type": "string"
+}Input schema / requiredPrevious value: -[
- "email"
-]New value: +[
+ "sessionToken"
+]my_coaching3 fields changedInput schema / properties / emailRemoved value: -{
- "description": "The user's email — their identity on Noemic",
- "format": "email",
- "type": "string"
-}Input schema / properties / sessionTokenAdded value: +{
+ "description": "The session token returned by login or register — proves which user is acting. Reuse it for the whole conversation; never a raw email.",
+ "minLength": 16,
+ "type": "string"
+}Input schema / requiredPrevious value: -[
- "email"
-]New value: +[
+ "sessionToken"
+]my_commitments3 fields changedInput schema / properties / emailRemoved value: -{
- "description": "The user's email — their identity on Noemic",
- "format": "email",
- "type": "string"
-}Input schema / properties / sessionTokenAdded value: +{
+ "description": "The session token returned by login or register — proves which user is acting. Reuse it for the whole conversation; never a raw email.",
+ "minLength": 16,
+ "type": "string"
+}Input schema / requiredPrevious value: -[
- "email"
-]New value: +[
+ "sessionToken"
+]my_connections3 fields changedInput schema / properties / emailRemoved value: -{
- "description": "The user's email — their identity on Noemic",
- "format": "email",
- "type": "string"
-}Input schema / properties / sessionTokenAdded value: +{
+ "description": "The session token returned by login or register — proves which user is acting. Reuse it for the whole conversation; never a raw email.",
+ "minLength": 16,
+ "type": "string"
+}Input schema / requiredPrevious value: -[
- "email"
-]New value: +[
+ "sessionToken"
+]my_credits3 fields changedInput schema / properties / emailRemoved value: -{
- "description": "The user's email — their identity on Noemic",
- "format": "email",
- "type": "string"
-}Input schema / properties / sessionTokenAdded value: +{
+ "description": "The session token returned by login or register — proves which user is acting. Reuse it for the whole conversation; never a raw email.",
+ "minLength": 16,
+ "type": "string"
+}Input schema / requiredPrevious value: -[
- "email"
-]New value: +[
+ "sessionToken"
+]my_intros3 fields changedInput schema / properties / emailRemoved value: -{
- "description": "The user's email — their identity on Noemic",
- "format": "email",
- "type": "string"
-}Input schema / properties / sessionTokenAdded value: +{
+ "description": "The session token returned by login or register — proves which user is acting. Reuse it for the whole conversation; never a raw email.",
+ "minLength": 16,
+ "type": "string"
+}Input schema / requiredPrevious value: -[
- "email"
-]New value: +[
+ "sessionToken"
+]my_profile3 fields changedInput schema / properties / emailRemoved value: -{
- "description": "The user's email — their identity on Noemic",
- "format": "email",
- "type": "string"
-}Input schema / properties / sessionTokenAdded value: +{
+ "description": "The session token returned by login or register — proves which user is acting. Reuse it for the whole conversation; never a raw email.",
+ "minLength": 16,
+ "type": "string"
+}Input schema / requiredPrevious value: -[
- "email"
-]New value: +[
+ "sessionToken"
+]port_context3 fields changedInput schema / properties / emailRemoved value: -{
- "description": "The user's email — their identity on Noemic",
- "format": "email",
- "type": "string"
-}Input schema / properties / sessionTokenAdded value: +{
+ "description": "The session token returned by login or register — proves which user is acting. Reuse it for the whole conversation; never a raw email.",
+ "minLength": 16,
+ "type": "string"
+}Input schema / requiredPrevious value: -[
- "email",
- "connectionId",
- "context"
-]New value: +[
+ "sessionToken",
+ "connectionId",
+ "context"
+]registerresolve_commitment2 fields changedInput schema / properties / sessionTokenAdded value: +{
+ "description": "The session token returned by login or register — proves which user is acting. Reuse it for the whole conversation; never a raw email.",
+ "minLength": 16,
+ "type": "string"
+}Input schema / requiredPrevious value: -[
- "commitmentId",
- "succeeded"
-]New value: +[
+ "sessionToken",
+ "commitmentId",
+ "succeeded"
+]respond_intro3 fields changedInput schema / properties / emailRemoved value: -{
- "description": "The user's email — their identity on Noemic",
- "format": "email",
- "type": "string"
-}Input schema / properties / sessionTokenAdded value: +{
+ "description": "The session token returned by login or register — proves which user is acting. Reuse it for the whole conversation; never a raw email.",
+ "minLength": 16,
+ "type": "string"
+}Input schema / requiredPrevious value: -[
- "email",
- "introId",
- "accept"
-]New value: +[
+ "sessionToken",
+ "introId",
+ "accept"
+]send_cue3 fields changedInput schema / properties / emailRemoved value: -{
- "description": "The user's email — their identity on Noemic",
- "format": "email",
- "type": "string"
-}Input schema / properties / sessionTokenAdded value: +{
+ "description": "The session token returned by login or register — proves which user is acting. Reuse it for the whole conversation; never a raw email.",
+ "minLength": 16,
+ "type": "string"
+}Input schema / requiredPrevious value: -[
- "email",
- "bookingId",
- "text"
-]New value: +[
+ "sessionToken",
+ "bookingId",
+ "text"
+]send_intro3 fields changedInput schema / properties / emailRemoved value: -{
- "description": "The user's email — their identity on Noemic",
- "format": "email",
- "type": "string"
-}Input schema / properties / sessionTokenAdded value: +{
+ "description": "The session token returned by login or register — proves which user is acting. Reuse it for the whole conversation; never a raw email.",
+ "minLength": 16,
+ "type": "string"
+}Input schema / requiredPrevious value: -[
- "email",
- "message"
-]New value: +[
+ "sessionToken",
+ "message"
+]send_message3 fields changedInput schema / properties / emailRemoved value: -{
- "description": "The user's email — their identity on Noemic",
- "format": "email",
- "type": "string"
-}Input schema / properties / sessionTokenAdded value: +{
+ "description": "The session token returned by login or register — proves which user is acting. Reuse it for the whole conversation; never a raw email.",
+ "minLength": 16,
+ "type": "string"
+}Input schema / requiredPrevious value: -[
- "email",
- "connectionId",
- "text"
-]New value: +[
+ "sessionToken",
+ "connectionId",
+ "text"
+]session_debrief3 fields changedInput schema / properties / emailRemoved value: -{
- "description": "The user's email — their identity on Noemic",
- "format": "email",
- "type": "string"
-}Input schema / properties / sessionTokenAdded value: +{
+ "description": "The session token returned by login or register — proves which user is acting. Reuse it for the whole conversation; never a raw email.",
+ "minLength": 16,
+ "type": "string"
+}Input schema / requiredPrevious value: -[
- "email",
- "bookingId"
-]New value: +[
+ "sessionToken",
+ "bookingId"
+]session_transcript3 fields changedInput schema / properties / emailRemoved value: -{
- "description": "The user's email — their identity on Noemic",
- "format": "email",
- "type": "string"
-}Input schema / properties / sessionTokenAdded value: +{
+ "description": "The session token returned by login or register — proves which user is acting. Reuse it for the whole conversation; never a raw email.",
+ "minLength": 16,
+ "type": "string"
+}Input schema / requiredPrevious value: -[
- "email",
- "bookingId"
-]New value: +[
+ "sessionToken",
+ "bookingId"
+]set_available_now3 fields changedInput schema / properties / emailRemoved value: -{
- "description": "The user's email — their identity on Noemic",
- "format": "email",
- "type": "string"
-}Input schema / properties / sessionTokenAdded value: +{
+ "description": "The session token returned by login or register — proves which user is acting. Reuse it for the whole conversation; never a raw email.",
+ "minLength": 16,
+ "type": "string"
+}Input schema / requiredPrevious value: -[
- "email",
- "open"
-]New value: +[
+ "sessionToken",
+ "open"
+]update_my_profile3 fields changedInput schema / properties / emailRemoved value: -{
- "description": "The user's email — their identity on Noemic",
- "format": "email",
- "type": "string"
-}Input schema / properties / sessionTokenAdded value: +{
+ "description": "The session token returned by login or register — proves which user is acting. Reuse it for the whole conversation; never a raw email.",
+ "minLength": 16,
+ "type": "string"
+}Input schema / requiredPrevious value: -[
- "email"
-]New value: +[
+ "sessionToken"
+]write_debrief3 fields changedInput schema / properties / emailRemoved value: -{
- "description": "The user's email — their identity on Noemic",
- "format": "email",
- "type": "string"
-}Input schema / properties / sessionTokenAdded value: +{
+ "description": "The session token returned by login or register — proves which user is acting. Reuse it for the whole conversation; never a raw email.",
+ "minLength": 16,
+ "type": "string"
+}Input schema / requiredPrevious value: -[
- "email",
- "bookingId",
- "strengths",
- "growth",
- "drill"
-]New value: +[
+ "sessionToken",
+ "bookingId",
+ "strengths",
+ "growth",
+ "drill"
+]list_people5 fields changedInput schema / additionalPropertiesAdded value: +falseInput schema / properties / availableNowAdded value: +{
+ "description": "Only people bookable this minute via book_now",
+ "type": "boolean"
+}Input schema / properties / freeFirstSessionAdded value: +{
+ "description": "Only people who do (true) / don't (false) offer a free first session",
+ "type": "boolean"
+}Input schema / properties / hasOpeningWithinDaysAdded value: +{
+ "description": "Only people with an open slot (or live presence) within N days",
+ "maximum": 60,
+ "minimum": 1,
+ "type": "integer"
+}Input schema / properties / maxHourlyRateDollarsAdded value: +{
+ "description": "Highest acceptable hourly rate in US dollars (e.g. 25 or 12.5)",
+ "minimum": 0,
+ "type": "number"
+}set_available_now3 fields changedInput schema / properties / minutesRemoved value: -{
- "description": "How long they are available from now; 0 to clear",
- "maximum": 480,
- "minimum": 0,
- "type": "integer"
-}Input schema / properties / openAdded value: +{
+ "description": "true = open to instant sessions right now; false = closed",
+ "type": "boolean"
+}Input schema / requiredPrevious value: -[
- "email",
- "minutes"
-]New value: +[
+ "email",
+ "open"
+]add_availabilityadd_to_my_corpusartifact_libraryassign_artifactbecome_availablebook_nowbook_sessioncancel_bookingcheck_messagesclose_briefcoaching_playbookcomplete_assignmentcomplete_sessioncreate_artifactcreate_commitmentfile_briefget_availabilityget_personget_startedlist_peoplematch_memy_artifactsmy_assignmentsmy_bookingsmy_briefsmy_coachingmy_commitmentsmy_connectionsmy_creditsmy_introsmy_profileopen_briefsport_contextresolve_commitmentrespond_introsend_cuesend_introsend_messagesession_debriefsession_transcriptset_available_nowset_passwordupdate_my_profilewrite_debriefConsent-based human matchmaking for peer advice, collaboration, and practical help.
Find founders, collaboration opportunities and events; manage authorized signups and messages.
Coach your communication from your own recorded conversations: talk-time, questions, rapport, more.
Launch and operate a SaaS from one conversation — domain, hosting, email, Stripe, ads, security.
Add one secure layer between your agents and this server.
